The key to sensible work with Codex is to understand that it is not an autocomplete with a long answer but a closed loop. At each step the agent interprets the goal, reads the available context, chooses a tool, observes the result and decides what to do next. The model does not know the repository in advance and does not automatically get every file - it sees only what a tool actually read. Understanding this loop matters more than any wording tricks: it explains why the agent is sometimes confidently wrong.
Hence the first rule: trust not the confidence of the wording but the evidence from tools. The phrase "it looks like Vitest is used" is a guess; the proof is a found package.json, a config and a specific command. The model can sound equally convincing both when it is right and when it is guessing, so its output is judged by the attached facts, not the tone. This distinction is the foundation of everything else in the book.
It helps to gather the evidence levels into a table once, to tell a weak claim from a checkable one. Below are four levels: discovery, change, verification and behavior. Each has its own evidence: a found command, an exact diff, an exit code with test output, a reproduction in the browser. You return to this map when judging any of the agent's results: it shows at which evidence level it stopped and where you still need to recheck.
The levels run from cheap to expensive, and this is not accidental. Discovery is confirmed by a read file, a change by an exact diff and a list of affected files, verification by an exit code and relevant test, typecheck or lint output. The strongest level is behavior: the app is built, run, and the result is seen via a browser or E2E reproduction or explicitly described as an unverified boundary. Skipping levels means taking an explanation for evidence.
| Level | Weak claim | Required evidence |
|---|---|---|
| 1. Discovery | "It looks like Vitest is used" | package.json, config and a found command |
| 2. Change | "The file is fixed" | An exact diff and a list of affected files |
| 3. Verification | "It should work" | Exit code and test/typecheck/lint output |
| 4. Behavior | "The UI is fixed" | Browser/E2E reproduction or an explicitly unverified boundary |
|---|
The second fundamental distinction is that tool rights are not equal to shell rights. The sandbox limits exactly the spawned commands: what the shell may read, write or send to the network. But apps, MCP, the browser, computer use and the cloud have their own additional controls on top of that. These are different planes of access, and keeping them separate is necessary so as not to explain behavior by the wrong cause.
From this follows a non-obvious but important rule. Approving one side-effecting connector call does not expand the filesystem sandbox: by allowing the agent to do an action via MCP or an app, you have not thereby given it access to files beyond the writable roots. Boundaries add up rather than transfer from one mechanism to another. Confusion here is dangerous: a person thinks they have "already allowed everything", while in fact they opened only one narrow channel.
The practical conclusion for requests is direct: the claim "Codex understood the project" is confirmed by evidence, not taken on faith. A good result names the cause, the changed files, the commands with exit codes, what was checked by observation and what remained unchecked. Such a report turns a vague "done" into a checkable statement and immediately shows at which evidence level the agent stopped - and therefore where your attention is needed most.
The typical failures around the loop are predictable. Taking a confident wording for a fact without asking for evidence. Stopping at a static check where observation of behavior was needed. And confusing the planes of access, deciding that an approved connector call expanded the file sandbox. Demand proof matched to the level of risk, tell tool rights from shell rights - and the loop becomes controllable rather than a stream of confident but unverified claims.