Codex cls, and why clearing context is a real skill

What people mean by codex cls

Two different things hide behind the query codex cls. One is muscle memory from Windows: people type cls expecting a blank terminal and get nothing useful. The other, and the one worth writing about, is wanting to reset the agent's conversation so it stops dragging a failed approach forward.

For the first, the shell answer works. clear on macOS and Linux, or Ctrl+L in most terminals, tidies the display. It does not touch what the model remembers. That distinction trips up more people than it should. A clean screen with a polluted conversation is the worst of both, because you can no longer see the wrong turn that is still influencing every answer.

For the second, use the session's own clear or new-conversation command rather than a shell command. Check the in-app help for the exact word, since these commands change between releases and we would rather you read the current list than trust a page written months ago.

When to clear and start again

Clearing is not a tidiness habit. It is a recovery tool with specific triggers:

• Two consecutive fix attempts that did not move a failing test closer to passing. The model is now anchored on its own wrong theory.
• You changed the goal mid-session. The old task's assumptions are still in the window and they leak.
• The agent keeps referencing a file it edited and then reverted. Stale state is the single most common source of confident nonsense.
• Responses have got slower and vaguer at the same time, which usually means the window is crowded.
• You are moving to a different part of the codebase. Frontend conventions bleeding into backend work produces odd hybrids.

Clear the branch too

A cleared conversation with a half-edited working tree is a trap. The model no longer knows what it changed, and the files still carry the changes. Reset both together. In practice that means git checkout . or a stash before you start the new session, so the repository and the conversation agree about reality.

Before clearing, take the thirty seconds to write down what you learned. The missing config file, the test that needs an env var, the module that actually owns the behaviour. Paste that into the fresh session as the opening brief. A restart that carries forward the findings but drops the failed attempts is usually the fastest path to a working diff, and it beats another twenty minutes of nudging by a wide margin.

The habit worth building

Long sessions feel productive because there is history to point at. In our workshops the engineers who finish tasks fastest are the ones with short sessions and good briefs, not the ones with an hour of scrollback. Treat a session like a branch. Cheap to create, cheap to throw away, never precious.

What to do next

Next time you catch yourself on a third correction in a row, stop. Write three lines of what you now know, clear the session, reset the working tree, and paste those three lines in. Time both approaches once and you will not need convincing again.

If you want help putting this into practice, talk to us.