Approvals & sandbox

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?

These are orthogonal. 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. You can also run the opposite. 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 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 several 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.