[BUG] Escape interrupt contaminates Claude's reasoning on all subsequent turns

What's Wrong?

When Escape is pressed to interrupt Claude, it writes an Interrupted · What should Claude do instead? marker into the conversation history. That marker stays in context for the rest of the session and contaminates Claude's reasoning on all subsequent turns. Claude continues to "remember" a step it never actually completed, and reasons around it even after the user explicitly corrects course.

This happens regardless of whether the interrupt was intentional — the problem is not the interrupt itself, but that the interrupt permanently alters the model's view of what was/wasn't done for the remainder of the session.

This is distinct from the closed/stale #23350 (which was about subsequent tool calls being auto-aborted). This report is about reasoning/context contamination: the model's narrative on later turns is wrong because the interrupt is baked into context.

What Should Happen?

Either:

1. An Escape interrupt should not persist a context-visible "Interrupted" marker that survives across turns and alters later reasoning, or
2. There should be a clean way to remove the interrupted turn from context (beyond Esc Esc rewind, which requires the user to notice the contamination and manually truncate).

Steps to Reproduce

1. Start a multi-step task (e.g. a slash command / skill that runs several ordered steps).
2. Press Escape mid-step to interrupt — an Interrupted · What should Claude do instead? marker is recorded.
3. Send a new instruction (even an explicit correction like "do not skip any step").
4. Observe: Claude's reasoning on this and later turns still references the interrupted step as "skipped before" / already-handled, even when it wasn't. The contamination persists for the rest of the session.

Example (observed)

During a multi-step skill run, an Escape interrupt was registered. On the next turn — after the user said "do not skip any step" — Claude still reasoned: "Running all 4 steps in order, starting with the vault sync I skipped before" and "Step 2 (snapshot) I already ran this session" — narrating around a step state created purely by the interrupt, not by anything that actually executed.

Impact / Why it matters

The interrupt silently corrupts the session's reasoning state, and the user has no obvious signal that it happened — they just get subtly-wrong behavior afterward. Telling Claude to correct course only partially works because the marker remains in context and keeps pulling reasoning back to the stale state. This is amplified when Escape is pressed by mistake (a single, easily-mis-pressed key), but the underlying defect is the same either way.

Workaround

• Esc Esc rewind to before the interrupt removes the marker, but requires the user to recognize the contamination first.
• Unbinding escape in ~/.claude/keybindings.json ({"context":"Chat","bindings":{"escape":null}}) prevents accidental interrupts, but then loses Esc-as-interrupt entirely. On Apple Terminal.app there's no way to rebind interrupt to a modified-Esc (Shift/Ctrl+Esc all collapse to plain Esc), so the only deliberate interrupt left is Ctrl+C.

Claude Code Version

2.1.193 (also reported on 2.1.29 in the related #23350)

Platform

macOS — Apple Terminal.app (TERM=xterm-256color)

Related Issues

• #23350 (closed/stale) — same root cause (Escape leaves persistent abort state), different symptom (auto-aborted tool calls vs. reasoning contamination).