Codex’s distinctive risk is not technical. It is that the work arrives wearing the costume of reviewed code. A pull request is the artefact a team produces after someone has read the change and agreed with it. When an agent opens one, you get the artefact without the reading — the branch name, the diff view, the green checks, the merge button — and every habit you have built around that screen tells you the work has already been through a gate. It has not. You are the gate, and the screen is doing a quiet job of implying otherwise. Like Cursor and Claude Code, Codex belongs to the half of vibe coding where you still own the code — the other half fails differently.
That is not an argument against using it. It is an argument for knowing which parts of a diff you cannot skim.
The tests passing is the weakest signal on the page
Green checks mean the code does what the tests say. If the same agent wrote the tests in the same task, then the tests encode the agent’s understanding of the requirement — so a test suite passing against agent-written tests is closer to internal consistency than to correctness.
This matters most for the bugs that are invisible to tests by nature. A missing ownership check passes every test, because the test signs in as the owner. A payment that can be submitted twice passes, because the test submits it once.
So read the tests as part of the diff, not as evidence about it. One useful question per test file: does any test here assert that something is refused? A suite with no negative cases — nothing checking that the wrong user gets a 403, that a bad input is rejected — is a suite that will stay green through the bugs you most care about.
Read the diff in this order
A large agent-written diff cannot be read line by line, and pretending otherwise is how it gets rubber-stamped. Go after the parts where mistakes are expensive.
Anything under a routes, api, endpoints or handlers path. This is where requests from strangers arrive. For each new or changed endpoint ask one question: where does it decide who is asking, and does it compare that to the thing being asked for? An endpoint that looks up a record by id and returns it, with no comparison against the session, is the single most common serious bug in AI-written code.
Anything touching authentication, sessions, tokens or middleware. Small diffs here have large consequences, and a one-line change to a guard is easy to scroll past in a 600-line pull request.
Migrations and schema changes. These are the part of a diff that is hard to undo after real data exists. Read what a dropped column or a changed constraint does to rows already in the table.
The dependency manifest. Every added package is code you are now shipping. Confirm you recognise each one and that the name is the package you think it is — near-miss names are a real supply-chain route, and a line in package.json is the easiest line in any diff to wave through.
Configuration and environment files. Look for anything that turns a protection off to make something work: a permissive CORS origin, a disabled certificate check, a debug flag, a raised limit.
What the sandbox does and does not cover
Codex runs each task in an isolated cloud environment with a copy of your repository, which contains what the agent does while it works. That is a real protection for your laptop and your network, and it is worth understanding precisely so you do not over-credit it.
It is not a protection for your users, because the output of the task is code, and that code leaves the sandbox and runs in production with your real database and your real keys. Containment during authorship says nothing about the behaviour of what was authored. If there is an escape-hatch mode in your setup that grants broader access, know whether it is on, and prefer it off for anything routine.
The other thing to check is what the environment was given. An agent that needs credentials to run your tests has those credentials; treat them as scoped to that job, not as your production keys, and confirm nobody handed it a token that can reach live data.
The app-level checks, which no review of a diff will give you
Some things are only visible in the running app. These take twenty minutes and are worth more than another pass over the diff.
Two accounts, two browsers. Create a record in account A, then try to load it as account B by changing the id in the URL or the request. This finds the bug the tests were never going to find.
Submit the same payment twice — click twice, or replay the request. If it charges twice, that is a refund and a support conversation for every customer it happens to.
Look at what the browser downloaded. View source on the deployed site and search for sk-, service_role, and SECRET. Anything a key needs to be secret for is broken if it is in there.
The habit worth keeping
The useful adjustment is small: treat an agent’s pull request as a proposal rather than a submission. Everything about the interface encourages the opposite, because the interface was built for a world in which a human had already read the code and was asking you to agree. Nobody has read it yet. Reading the five places above is not a full review, and it is enough to catch the failures that actually reach users.
Written September 2026. Codex’s modes and defaults move; what a pull request cannot tell you about code nobody has read does not.
Questions people ask
Is code from a Codex pull request safe to merge?
Not on the strength of it being a pull request. A pull request is the artefact a team produces after someone has read a change and agreed with it, so every habit around that screen implies the work already passed a gate. When an agent opens one, nobody has read it yet. Treat it as a proposal rather than a submission.
The tests pass on the Codex PR. Is that enough?
Green checks are the weakest signal on the page when the same agent wrote the tests in the same task, because then the tests encode the agent's understanding rather than the requirement. The bugs that matter are invisible to tests by nature: a missing ownership check passes, because the test signs in as the owner. Check whether any test asserts that something is refused.
What should I actually read in a large agent-written diff?
Five places. Anything under routes, api or handlers, where requests from strangers arrive. Anything touching authentication, sessions or middleware. Migrations, which are hard to undo once real data exists. The dependency manifest, because every added package is code you now ship. And configuration, for anything that turns a protection off to make something work.
Does the Codex sandbox protect my users?
It protects your laptop and your network while the agent works, which is real. It does not protect your users, because the output of the task is code, and that code leaves the sandbox and runs in production with your real database and your real keys. Containment during authorship says nothing about the behaviour of what was authored.
The same question, other tools
Each of these is a different problem rather than the same article renamed — what goes wrong depends on whether the tool wrote code you can read, or configured a platform you cannot.