Escape in the main input kills running background agents
What happens
Pressing <kbd>Esc</kbd> while focused in the main prompt input terminates background agents that are still running. The agents are killed silently — the next indication is a task notification reporting they never completed and that their in-process state was lost.
What I expected
<kbd>Esc</kbd> to cancel or clear the current input, and to interrupt work that is in the foreground. Background agents are backgrounded specifically so the session stays usable while they run: sending a message, editing input, and cancelling a keystroke are all things a user does because the work is not in the foreground. If <kbd>Esc</kbd> tears them down, "background" doesn't mean anything.
Steps to reproduce
- Launch a long-running agent with
run_in_background: true. - Click into the main prompt input while it is working.
- Press <kbd>Esc</kbd> (in my case: a misclick, then Esc to dismiss).
- The agent dies. A
<task-notification>later reports it as failed/incomplete with its state lost.
Impact
Real work is destroyed with no warning and no confirmation. In this session an agent was most of the way through a code change; it had not yet committed, so everything since its last commit was gone and the task had to be dispatched again from scratch. That is wasted wall-clock time and wasted tokens, and it is unrecoverable — there is no "restore agent" and the transcript is gone too, so even reconstructing what it had done is impossible.
It is also a trap rather than a mistake a user learns from: <kbd>Esc</kbd> is the universal "never mind" key, so the instinct that triggers the bug is the correct instinct everywhere else in the interface.
Suggested fix
Either scope <kbd>Esc</kbd> in the main input to the input and the foreground only, leaving background agents alone; or, if killing them is genuinely intended, require a confirmation naming what is about to be destroyed — and never on a bare single keypress.
Environment
- Claude Code 2.1.233, desktop app
- macOS 26.6.1