Gate the idle Ctrl+C "stop all background agents" behind the existing two-press confirmation, or make it opt-out

Summary

At an idle prompt with background agents running, a single Ctrl+C stops every background agent with no confirmation, and Claude can't resume them afterwards. Every other route to the same outcome in the CLI is gated:

• chat:killAgents (Ctrl+X Ctrl+K) needs a second press within 3 s and shows a hint.
• Esc leaves background agents running. The VS Code extension matched this in 2.1.284/2.1.286.
• The gesture itself shipped with a two-press gate in 2.1.49.

Ctrl+C is also the documented "clear input" key and is reserved (can't be rebound), so an accidental press has no workaround.

This is a proposal for one small change, not another incident report. Incident reports for the same trigger: #95081 (macOS, 2.1.257), #81765, and earlier #79591 / #81056 (auto-closed stale). Esc variant: #21167. Resume after an accidental stop: #83809.

Environment

• Claude Code 2.1.285. The same code path is present in 2.1.286.
• Windows 11, Windows Terminal, inside an RDP session.

Steps to reproduce

1. Start claude and ask it to launch two background agents with a long task (Agent tool with run_in_background).
2. Wait for the turn to finish, so the prompt is idle while the agents are still running.
3. Press Ctrl+C once.

Actual: "2 background agents were stopped by the user", immediately. There's no "press again" hint and no confirmation. Claude can't resume the agents afterwards (SendMessage returns "was stopped by the user and was not resumed"), so their work has to be relaunched. Inferred from reading the code, not separately observed here: the same happens when the prompt contains text.

Expected: per the interactive-mode docs ("If nothing is running, the first press clears the prompt input and a second press exits Claude Code"), the first press should clear the input. Alternatively, it could show the same "press again to stop N background agents" hint that Ctrl+X Ctrl+K shows.

Why it matters

Ctrl+C is a reflex key, and terminal muscle memory, home-row-mod keyboards and a held modifier all produce it by accident. Here it fired unintentionally twice on 2.1.285, killing 3 agents and 1 agent. In one case it came 1.35 s after a turn ended, and the next prompt started with a stray "c". The cost is asymmetric: the accidental action is irreversible, while the deliberate action already has a dedicated, confirmed binding.

Proposed change (primary)

Route the idle-prompt Ctrl+C agent stop through the same two-press confirmation that chat:killAgents already uses, and never stop agents on a Ctrl+C that has input to clear.

This part is inferred from reading the 2.1.285 bundle and may be wrong in the details. Only two call sites emit the agents_killed record:

• the chat:killAgents handler, which already requires a double press;
• the shared cancel routine, when called without suppressBackgroundAgentKill. The Esc path and the agent-view Ctrl+C path already pass that flag.

If that's right, the change is a flag on one call site plus the existing hint. Ctrl+X Ctrl+K and Ctrl+C's interrupt/exit behaviour stay as they are.

Fallback (if the single-press gesture is intentional)

Expose it as a setting, e.g. stopBackgroundAgentsOnCtrlC: false (or an env var). Users who hit this could then turn the Ctrl+C path off and keep Ctrl+X Ctrl+K as the bulk stop. Ctrl+C is reserved, so this can't be done from keybindings.json today.

Either way, the Ctrl+C row in the interactive-mode docs should mention the agent-stop behaviour, since it currently doesn't.