Skip to content

Course · Claude Code · Sessions & context

Clear the conversation with /clear

Say the health-check patch is parked: the work is recorded in a handoff note, and the discussion that produced it can wait. Before continuing it, you want to answer a separate question in the same service: where does a payment key become marked as seen? The old conversation contains route registration, app extraction, and test-server cleanup. None of those details answers this question.

The starting condition is an active Claude Code conversation open in a repository; the health patch and the payments service are the running example, but any parked task in your own repository serves the same purpose (the install lesson covers opening a session in a repo). Keep the health handoff you made (the resume lesson shows how), then enter at the prompt of that conversation:

/clear

This starts a new conversation; the old one remains accessible through /resume. It does not undo the health patch. The command reference documents the reset and return path. Use a separate terminal to check git status --short before and after if you want to see the distinction directly.

The new task can be read-only, so there is no need to disturb unfinished edits. An idempotency key identifies one logical request so that a retry with the same key can be recognized instead of charging twice. If you have the payments example source prepared for this course (an Express + TypeScript service with payment code under src/payments/), send this prompt; otherwise read the excerpt that follows, or ask the same shape of question about a function in your own repository:

Trace how this service handles a repeated idempotency key.
Read src/payments/processor.ts and the helpers it calls.
Where is a key first recorded? Does checking the key change any state?
Show the supporting lines. Do not edit files or run payment requests.

In the example source, processPayment calls checkIdempotency. That helper lives in src/utils/idempotency.ts. Its name suggests a question, but its body also performs an action. The following is an excerpt from that starting source, not a captured agent response:

export function checkIdempotency(key: string): boolean {
if (seen.has(key)) {
return true;
}
seen.set(key, Date.now());
return false;
}

Trace a new key through those lines. It is absent, so the helper records it and returns false. A second call with the same key finds the entry and returns true. The first “check” has changed the state that the second check observes.

That is a useful finding even before you decide whether it is the right design. It also limits the claim you can make: these lines show an in-memory key check with a write. They do not prove the entire payment path handles retries correctly across failures, restarts, or multiple processes. A familiar function name is not a substitute for tracing its effects.

The health changes remain in the working tree throughout this investigation. A new conversation could still edit them if you asked it to. For independent code changes, you would need to manage the working files as well; the branching lesson will show that separation.

Clearing also does not mean the model runs without system instructions, tools, or applicable project guidance. It replaces the conversation: the agent’s context no longer contains the earlier discussion, while files, tools, and project guidance still enter it. Avoid treating “fresh” as either “isolated” or “unconfigured.” And Ctrl+L is only a terminal-display action, not a substitute for a conversation reset; see the keyboard reference.

Record the key-check finding in your notes, then use /resume to select the earlier health conversation. --continue would select the most recent conversation, which may now be this investigation. Before trusting the resumed discussion, compare what it or your handoff claims is finished and unfinished with the current git status --short and git diff.

You have changed what you were discussing without claiming to repair the payment processor. The health patch may still be waiting exactly where you left it. Next, consider a different problem: the conversation is right, but the agent’s latest edit is wrong.