Left-arrow at position 0 in the composer navigates screens, killing running background agents

Summary

With the cursor in the text composer, pressing Left-arrow when the cursor is already at
position 0 does not no-op — it navigates to a different screen. Any background agents
running at that moment are killed as collateral. Their work is unrecoverable: the harness
refuses to resume a user-stopped agent, so in-flight reasoning and unreported findings are
lost even when the agent's on-disk output survived.

Repro

1. Start one or more long-running background agents (Agent tool / subagent dispatch).
2. Paste text into the composer — e.g. content pasted by mistake, which is the common

real-world trigger.

1. Move the cursor to the start of the pasted text and press Left-arrow once more to keep

walking left.

1. The UI navigates to a different screen. Running background agents are terminated.

Expected

Left-arrow at position 0 in a focused text input is a no-op, as it is in every other text
field on the platform. Screen navigation should not be bound to a key that a focused
composer is actively consuming.

Actual

Focus escapes the text field and the keypress is handled as navigation. Background agents
are killed with no confirmation and no undo.

Why this is worse than a normal misnavigation

The destructive part is not the navigation, it is that it is silently coupled to killing
background work.

• There is no confirmation prompt, so a single keystroke destroys minutes-to-hours of

agent work.

• It is unrecoverable: SendMessage to a user-stopped agent returns "was stopped by the

user and won't be resumed."

• The user never expressed intent to stop anything. The keystroke was aimed at editing

text.

• It fires most often while cleaning up an accidental paste — so the user is already

correcting one mistake when the second, costlier one triggers.

Suggested fixes, most valuable first

1. **Do not overload keys commonly used in text editing to perform major or destructive

actions.** Arrow keys, Home/End, Backspace and the like are consumed constantly while
editing; binding one of them, unmodified, to screen navigation guarantees
misfires. If a keyboard shortcut for this is genuinely wanted, require a modifier —
Shift-Left, or a chord. This is the general fix, and position-0 Left-arrow is only the
instance that happened to be found.

1. Decouple screen navigation from killing background agents. Leaving a screen should

background running work, not terminate it. Navigation is not a stop signal. Even with
fix 1, any other route off the screen still destroys work.

1. Confirm before terminating running agents, whatever the trigger.
2. Allow resuming a stopped agent, or at minimum surface its partial report, so an

accidental stop is recoverable rather than terminal.

1. Do not guard this by requiring a second press of the same key. That is a poor

defense against accidental presses, because accidental presses arrive in repeats.
Walking a cursor to the start of a line means pressing Left several times in a row, and
key auto-repeat delivers them faster than a human can react — so a "press it twice"
confirmation fires on exactly the input it is meant to catch. A guard has to be a
different input from the one being guarded: a modifier, a chord, or an explicit
prompt.

Environment

• Claude Code CLI, macOS (Darwin 25.5.0)
• Reproduced repeatedly in normal use; not a one-off