Two profiles as a daily habit: budget-audit and budget-build

You met profiles twice already in this course. You bundled approval and sandbox into one named profile so you’d stop re-typing the two trust flags every launch, and you bundled a model and an effort level so the right gear came pre-selected for the kind of work. This lesson isn’t a new feature on top of those - it’s the habit that makes them pay off, and it’s the first rung of this chapter’s ladder. A profile you defined once and forgot about saves you nothing. A profile you reach for by name a dozen times a day is most of the difference between Monday’s 11 turns and Friday’s 2.

The whole habit comes down to a small, almost trivial-sounding idea: have two profiles for budgetcli, and treat switching between them as part of how you work, not an occasional config change.

Why exactly two, and why these two

Across a real day on budgetcli you’re doing one of two fundamentally different things, and they want opposite postures.

Some of the time you’re exploring: reading the categorisation rules engine to understand it, asking the agent to trace where a number comes from, figuring out what you want to change before you change anything. During this, the agent should not be writing files at all, and it certainly shouldn’t be running shell commands that reach your real ledger.

The rest of the time you’re building: you’ve decided on the change, you want the agent to edit, run the tests, iterate. Here a read-only posture is just friction - every edit becomes an approval prompt, and you tune out the prompts, which is worse than not having them.

Those two modes want different settings on every dial you’ve learned, so bundle each into a profile and name them for what they’re for, not for what they contain:

~/.codex/budget-audit.config.toml

approval_policy = "never"
sandbox_mode   = "read-only"

~/.codex/budget-build.config.toml

approval_policy = "on-request"
sandbox_mode   = "workspace-write"

budget-audit is the profile you already built in the approvals chapter - never paired with read-only. That pairing isn’t careless; it’s safe by construction. Nothing under read-only can write, so there’s nothing an approval prompt would be protecting you from, and never lets the agent explore at full speed instead of stopping to ask permission for a write it isn’t allowed to make anyway. budget-build opens the sandbox to workspace-write so edits and tests can happen inside the project, and keeps on-request - the agent asks before anything consequential, and you’re there to answer.

Be precise about your own file here, because you already opened it further than that. The budget-build you wrote in the approvals chapter carries network_access = true and a writable root at ~/budget-data, deliberately, so it could reach the real exchange-rate API. That reach is the one line in this profile worth re-reading every so often - the default protects you, your own override is what decides what budget-build can actually touch.

A profile can carry more than the trust dials - model and reasoning effort belong here too, since a layer file takes the same top-level keys config.toml itself does (the config reference has the list). You could give budget-build a heavier effort for the categorisation work and leave budget-audit light. Resist over-engineering it. The two-profile habit works because it’s two, not eight; the moment you have a profile for every micro-mood you’ve recreated the friction you were trying to remove.

Switching is the actual skill

Defining the profiles took thirty seconds. The skill - the part that’s a habit - is reaching for the right one at launch and switching the moment the task changes underneath you.

Launch into a profile with --profile (short -p):

codex --profile budget-audit

You’re now exploring with the agent unable to touch anything. When the exploring turns into a decision - “right, I know what the rule change is, let’s make it” - that’s the switch. End the read-only session and relaunch into budget-build:

codex --profile budget-build

The trigger to switch is not a clock or a checklist; it’s the shape of the task changing. The instant you go from “help me understand this” to “make this change,” your posture should change with it. Run the build, get the edit reviewed and committed, and when you drop back into “now let me check what else this affected,” you drop back to budget-audit.

If you find yourself living in one profile most days, wrap its -p in a shell alias so a bare codex lands you there, and reserve the explicit flag for the switch. Most people on budgetcli will want budget-audit as that default - exploring is the safer place to land by accident.

The first rung: from 11 to 6

Put a number on the habit instead of trusting the feel of it. Chapter 1’s cold Monday run - no AGENTS.md, no profile, dials set by hand or not at all - cost 11 turns and reintroduced the float-money bug three times. Add the two things already in place by now - the rules file that states the money convention before Codex’s first move, and a named profile so the trust posture doesn’t have to be re-derived every launch - and chapter 7 already measured what’s left: the same job, run as a plain prompt with the rule and the profile already set, costs 6 turns and 0 reintroductions.

The reintroductions disappear completely, because AGENTS.md is read whether or not you remember to mention the money rule that session. The turns don’t disappear yet, because nothing here has packaged the procedure - you’re still describing the five import steps by hand, and a fresh misunderstanding about which column is which still costs a turn of correction the same way it always has.

Two named profiles and a rules file are worth five turns and every reintroduction. They are not worth the other four turns, and that honest gap is next lesson’s job.

Next, the other half of daily friction, and the rung that closes the rest of the gap: briefing the agent well and smoothing the editing surface.