Start unrelated Codex work with a fresh session or /fork

The cents refactor is finished. The categoriser’s in, the reports endpoint reads integer cents, the tests are green. The next thing on your list - adding a GET /accounts/{id}/balance endpoint - has nothing to do with any of it. Different files, different shape of work, different headspace.

Here’s the trap. The session is right there, warm and full of context, so you just start typing the new task into it. But this thread is saturated with the refactor: float-to-cents conversions, the model edits, the importer, command output from a dozen test runs. All of it is still in the window, and all of it now works against you. You’re paying for it on every turn, and - worse - it’s quietly steering the agent, which now reasons about a read endpoint through the lens of a money-handling migration. Ask it to add the balance route and don’t be surprised when it wonders whether the change affects the cents conversion.

You learned earlier in this chapter not to resume unrelated work, and not to let a tangent bleed into the main thread. This is the same principle one step further: when a line of work is genuinely finished, don’t carry its residue into the next thing. You want a clean slate - without losing your place in the terminal.

Two ways to leave the old context behind

The exact slash-command list varies by Codex surface and access. The current reference documents /fork for copying a local chat and /compact for reducing the current context; it does not promise /clear or /new as universal commands. For a genuinely clean thread, start a fresh codex invocation:

codex       # launch a new interactive session in the current project
codex fork  # branch an existing session when you want its history

Use a fresh invocation when the next task should not inherit the old conversation. Use /fork or codex fork when the old conversation is useful evidence for a second approach - a fork is not a clean slate, it carries the prior history on purpose, at the double-history price you paid earlier this chapter. Use /compact when the work is still the same and only the context needs reducing.

$ codex
> add a GET /accounts/{id}/balance endpoint that returns the account's
  current balance in integer cents

  [reads src/budgetcli/routes/accounts.py, src/budgetcli/models.py ...]

The agent goes straight to the accounts route. It doesn’t reach for the importer, doesn’t ask whether the new endpoint needs a cents migration, doesn’t burn tokens re-reading refactor context it will never need. The reset wiped what the agent knew - every file you changed still sits exactly where it was on disk.

Choosing between them

The practical line: launch a fresh codex session when the next task is unrelated, use /fork when you want to compare a second approach from shared history, and use /compact when you are continuing the same work but the context is crowded. Check the current slash-command reference because command availability varies by environment and access.

One thing both share, and it’s the warning that matters most: a reset is not an undo. Anything in the thread you’ll want later - a decision you reached, a useful finding, a TODO the agent surfaced - needs to be on disk before you wipe: in a commit, a note, or AGENTS.md. Reset when you want the thread gone, and only once what mattered has somewhere durable to live. This is the one thing none of the six moves in this chapter can do for you - not resume, not fork, not compact, not a fresh session. Every one of them manages what the agent remembers. None of them decides what’s worth remembering. That call stays yours, every time.

The decision under the whole chapter

Step back and almost every move in this chapter has been the same question asked from different angles: am I continuing this line of work, or leaving it?

• Continuing across days → resume it.
• Continuing, but exploring a fork in the road → /fork.
• A disposable detour, then back → /side.
• Continuing, but out of room → /compact it.
• Not sure which → /status and read the statement.
• Done, moving to something unrelated → launch a fresh codex session.

Pick the wrong side of that question and you either throw away context you needed or keep paying for context you didn’t. The skill isn’t any single command - it’s treating the agent’s window as a budget you can see, spend, fork, reclaim, and reset at will.

The ledger, three rows in

Chapter 1 opened the ledger with two rows, abbreviated here:

Move	Tokens	Turns	Blast radius	Recurs?
Read-only question (ch 1)	~3,900 est.	1	None	No
Fix the CSV date bug (ch 1)	~2,100 est. (code)	4	Money-adjacent, briefly drifted	Partly
Manage a week’s context - resume, fork, side, compact, status, reset (this chapter)	Kept under budget: the three biggest reads alone would’ve cost 17,900 est. (~9% of window) if left in place; compaction gave most of that back at roughly 450x	+1 short turn per boundary check - resume, a fork, a /status glance, a reset - cheap against the turns saved by never re-explaining	None - every move in this chapter touches what the agent remembers, not the repo	No - which command to reach for isn’t written anywhere the agent can read; you rebuild the judgment call every morning

Read that last cell the way you read the villain cell in chapter 1. The code from this chapter’s work is on disk, committed, safe. The discipline - resume when continuing, fork when comparing, side for a disposable question, compact when crowded, status when unsure, fresh when done - lives only in your own head. Nothing about it survives into a session that hasn’t got you in it. That’s the villain again, from a new angle: the judgment of what to do with the window is exactly the kind of thing that gets re-paid every session, because nothing here writes it down.

Now: controlling what the agent can do

The sessions are under control. You can carry days of budgetcli work without the window collapsing, and start clean when clean is what you need.

But notice what you’ve been quietly trusting this whole chapter: that letting Codex read your importer, edit your models, and run your tests against your own financial data is fine. So far it has been - but the moment the work touches the real ledger, the question stops being “can I keep the context tidy” and becomes “what is this agent actually allowed to do with my money’s data.” Now that the sessions are in hand, the next thing to get under control is the agent’s reach: what it can touch, what it must ask before doing, and why the network is off by default when real financial records are on the table. That’s Chapter 3 - approvals and the sandbox.