Approvals & sandbox

Two chapters in, you’ve learned to read what Codex proposes and to keep its window pointed at the right facts. Neither habit changes the one thing that hasn’t moved since chapter 1. Reading a file is not the same as knowing a repo, and Codex only ever has the first. At some point you have to let it act anyway - run a command, write a file - before it has earned the kind of trust a teammate earns over months, because acting is the only way any of this gets done. This chapter is about the two decisions you make instead of trust: how much Codex can do before it has to ask you, and how far it can reach while it’s doing it.

The work so far has been gentle: a date-parse fix, a few sessions of reading and proposing. This chapter is where it gets real, because budgetcli is about to hold your money - real accounts, real transaction history imported from your own bank statements. The moment that’s true, a question you could wave off before becomes load-bearing: when this agent runs a command or writes a file, what exactly is it allowed to touch, and what can it reach out to on the network?

Most tools answer that with a single trust slider - more autonomous or less. Codex splits it into two independent dials, and getting them straight is the whole of this chapter:

• How much it can do without asking you - the approval policy. Does every command stop for a y/n, only the risky ones, or none of them?
• How far it can reach - the sandbox. Read-only? Allowed to write inside the project? Or off the leash entirely, with network and the whole filesystem in play?

Here’s the trade a single slider forces on you: turn it up enough to stop babysitting safe, mechanical work, and you’ve also turned up how far a wrong guess could reach - because on one dial, less interruption and more reach are the same knob. You can run an agent that never interrupts you but still can’t escape the project directory or touch the internet - which, on a repo full of your financial data, is exactly the combination you want most of the time. Tools that fuse the two into one slider can’t express that; Codex can, and once the two-axis model clicks you’ll set both by reflex. The two risks aren’t the same risk, so they don’t get the same dial.

The week we’ll follow

You’re carrying on with budgetcli, and this stretch of work is precisely the kind that makes both dials matter at once:

• A money-handling refactor across six files where stopping for every edit is pure friction - but you still don’t want the agent escaping the project - start from the two-axis model, then pick a sandbox and an approval policy.
• A foreign transaction that needs a live exchange rate - the agent reaches for the rate API and can’t, because network is off by default. That’s the chapter’s sharpest teachable moment - network and writable directories.
• A data directory outside the repo where your imported statements live, which the agent needs to write - same lesson.
• The realisation that you keep re-typing the same two flags every launch - bundle them into a profile, and learn the one flag you should never reach for on this repo.

The through-line: a single fused “trust level” is the wrong shape for real work, because how much you let it do and how far you let it reach are different risks with different answers. By the end you’ll set each independently - loose on approvals where the work is tedious, tight on the sandbox because it’s your money on the line.

Start with the model everything else hangs off - the two axes, and why they’re separate.