Codex Fits Work That Lives in a Repo
You assign a change you can accept, not a chat about code. Short Q&A, office files, and teammates that keep running after you close the lid belong elsewhere.
Codex is a coding agent: you give a goal, it reads code, edits files, and runs checks in the folder you picked. Official docs keep it apart from generic chat and from document work — coding goes to Codex, short questions stay in chat, research documents take another workflow.codex-overview codex-quickstart The wrong shape cannot be saved by the five steps.
After reading, you should be able to answer:
- What kind of work belongs on Codex?
- Which three kinds should you not send it?
- How does this sit next to the four kinds of coding tools?
Fits: a change you can accept in the repo
A small feature, a missing test, a fix from a failing log, a review of one diff. Three shared traits: the object is code and project files; the result is a change; acceptance is a command or a diff, not “looks right.” Terminal, editor, and cloud coding are doors into the same kind of work, not three products.
The first job still has to pass pick the first job: small, reversible, obviously right or wrong. A whole-repo rewrite, or a merge to main, is not first.
Does not fit: the artifact is not in the repo
- Short Q&A. “What does this function do” is a question, not an assignment. Use chat. Do not open a coding agent.
- Office artifacts. Weekly notes, decks, tables in company docs. See Doubao Work or WorkBuddy.
- Work that must keep going in other people's sites after you close the lid. That is a cloud teammate. See Grok Bot.
It does not fight the four kinds of tools
Four kinds of tools, enough is enough puts Codex in the CLI-agent class: which main tool you pick when you write code. This article asks whether this job should go to Codex at all. Once it is the main tool, the handoff is the five steps in this section, and standing rules live in the project contract. Next, run one small change through the five steps.