Codex
Second coding agent
OpenAI's coding agent. It runs in the terminal, reads and edits a repository, and runs commands under a configurable approval and sandbox policy.
I run Codex alongside my main agent rather than instead of it. Two agents from different vendors disagree about code in useful ways, and having a second one set up means a review is a command rather than a project. Most of the setup work was making it obey the same house rules as everything else.
How I use it
Same guardrails, different engine. The rule I care most about is that nothing gets deleted, only moved to an archive folder. That rule was already enforced on my main agent by a hook. Codex uses the same hook event names and the same JSON contract, so the guard was a port rather than a rewrite, and both agents now refuse the same commands.
Approvals off, guards on. Being asked to approve every command is a good default and a bad workflow, so approvals are off and the safety lives in hooks instead. A hook that denies a call still works when approvals are off, which is what makes that trade acceptable. Take away the prompts and the hook is the only thing left, so it has to be tested rather than assumed.
As a second opinion on a plan. Handing the same problem to a different agent and comparing the two answers is cheap. Where they agree I stop worrying. Where they disagree is usually where the real decision was hiding.
Kept boring on purpose. No elaborate configuration, no long instruction stack. It is a clean pair of eyes, and loading it up with my house context would make it a copy of the agent I already have.
What I have learned the hard way
Configuration is read once at launch. Change the config and the running session keeps the old policy, silently, so a test of your new setting is really a test of the previous one. Restart before you conclude anything about a config change.
Where a key sits in the config file changes what it means. The top level settings have to appear before the first section header. Put them after one and they are read as part of that section, which is not an error, just a setting that does not apply. Nothing tells you.
Editing a hook invalidates its trust. The tool records a hash of the hook file, so changing it makes the next session ask whether the hooks should be trusted. Sensible behaviour, and a surprise the first time it happens in the middle of an automated run that had nobody there to answer.
A hook that never denies anything has not been tested. I only believed the delete guard after watching Codex actually refuse a delete and finding the file still there afterwards. A guard whose failure mode is silence has to be proven by making it fire.
Resources
This is one part of a stack. The rest is on the tools page, and what I build with it is on work.