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 because it carries the prior history. 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, not what it had done - every file you changed 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: 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.

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 answer.
• 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 context as a resource you can see, spend, fork, reclaim, and reset at will.

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.