Left arrow accidentally navigates to agents screen (not rebindable) and breaks main session view on return

Follow-up: visual artifact on return

After navigating back from the agents screen into the main session, a stray autocomplete/suggestion-style bar (highlighted blue, showing what looks like a leftover/stale suggestion — e.g. "Find uncommitted HTML mockups for B2C and B2B landing pages") remains rendered directly above the chat input, even though nothing was being typed and no autocomplete should be active. This looks like stale UI chrome bleeding through from a different state rather than a clean restore of the input area.

I’m experiencing this damn bug as well.
When I’m watching YouTube while letting the AI work, I inevitably end up pressing the left arrow key.
When are you going to fix this long-standing bug? What’s worse is that once this bug occurs, there’s no way to recover from it, so I have no choice but to restart.

The bigger problem is that after this bug happens, 100% of the conversation after the point where the bug occurred is completely omitted during resume or continue.

Yep, nasty bug. Twice now I've bumped the left arrow only to have to start from scratch on that main session. As far as I'm concerned the agent switcher is basically a long-winded way of doing /clear. Would love to be able to turn this off, or at the very least, go back to my original session without losing my work.

Root cause from the bundled binary (v2.1.207), in case it helps triage:

1. left: null in the Footer context doesn't disable it. The Footer context maps left → footer:previous / right → footer:next, but setting { "context": "Footer", "bindings": { "left": null } } and restarting does not stop the left arrow from opening the agents screen (confirmed on 2.1.207) — matching the "not rebindable" in the title. The agents-screen navigation isn't governed by the user keybinding for footer:previous.

2. The footer hint is a hardcoded glyph. The ← for agents hint renders a constant ("←") with no lookup of the configured binding, so even after remapping footer:previous the footer keeps showing ←.

A workaround that does stop it: CLAUDE_CODE_DISABLE_AGENT_VIEW=1 (or "disableAgentView": true in settings.json) removes the agent view, so the left arrow has nothing to navigate to. Two caveats: the agent view is shared across all running sessions (an on-demand daemon), so a per-session env var isn't enough — it has to be set globally and every running session restarted. And per the setting's own description it also disables --bg, /background and the on-demand daemon that background/remote-control sessions run on — so it's a blunt instrument, fine if you don't use the agents panel but not if you rely on background sessions.

Proper fix: (a) honor an unbound/remapped footer:previous for the left-arrow dispatch, and (b) resolve the hint glyph from the active keybinding.

really hard ux. i don't really like the "agents" screen... it bascially lists prior threads, but not all of them, and no real logic to why some appear there ffrom what i see, and when you "navigate into one" it could be running in another terminal and no way to know "which one you were just in" if you accdentally get there (easy to do, just press the left arrow). no indicator that 'this thread is currently loaded in another terminal'. there is a running indicator at least.

The fact that this seems to make it impossible to resume the session properly afterwards makes this quite serious in my view

+1 — hit this again today. With an empty chat input, an accidental left-arrow press sent my main session to the background/agents screen with no confirmation. Getting back to the original thread is disorienting (it's not obvious the session is still there or how to return to it).

A single unmodified arrow key is too easy to press accidentally for a navigation action this disruptive. A modifier chord, a confirmation, or at minimum making the binding configurable would help a lot.

Data points from hitting the same thing on WSL2 (v2.1.205):

There is a switch for this: leftArrowOpensAgents, toggleable in /config ("← opens agents"). But three gotchas make it nearly undiscoverable:

• It's only read from the /config store (~/.claude.json). Setting "leftArrowOpensAgents": false in ~/.claude/settings.json is silently ignored, and nothing in the docs warns that it isn't a settings.json setting.
• It has no action in the keybindings system, so keybindings.json can't touch it (matches what you found).
• It only disables the foreground shortcut. In an attached background session, ← is a hardcoded "detach to agents view" that ignores the setting — so once a session has been accidentally parked, every ← throws you back to the agents screen until you fork the conversation out with --resume --fork. Double Ctrl+D also stops exiting in that state (documented detach behavior, but surprising when one stray arrow key got you there).

+1 on both requests. Also seeing the garbled screen on return (WSL2 / Windows Terminal) — that part seems tracked in #76349.

Reproduced on macOS with Claude Code 2.1.218.

After pressing Left on an empty prompt to move a foreground conversation into Agent View, then reopening that same conversation:

• /quit detaches back to Agent View instead of exiting, confirming that the conversation is now attached as a background session.
• A new user prompt is persisted to the transcript, but no assistant, thinking, text, tool, retry, or error event follows.
• The Agent View state remains working while queued work, task count, and in-flight kinds are all empty.
• Ctrl+C and resending in the same CLI process does not recover.
• Fully exiting only the affected Claude Code process and starting a fresh foreground session restores normal responses. An OS reboot is not required. The old Agent View row remains incorrectly marked working.

This was not a tool or queue wait: there was no recorded assistant/API stream event after the prompt. I did not observe an authentication error or verify any /status change, so I cannot attribute this to a custom endpoint or authentication propagation issue.

can I disable the left arrow and background stuff altogether? I really don't use this or like this feature.

Additional detail on the degraded state after returning from agents view: IDE integration features stop working.
Editor line selection context and open file context are no longer injected into the session.
The session appears to lose its connection to the IDE, consistent with being reclassified as a regular agent rather than the primary session.

this is super annoying

it also resets the session usage statistics (tokens etc)

super annoying

Yes this is a garbage UX. Stray left arrow and now a session no longer stops when you hit ctrl-c twice, it keeps running in the background which could be a very bad thing.

Adding a third consequence to item 1 that I don't see reported yet: the accidental navigation permanently kills MCP development-channel inbound delivery for the rest of the session.

Reproduced on v2.1.228, macOS.

Symptom. Session launched with --dangerously-load-development-channels server:<name>. Channel notifications were delivering normally. Pressed left-arrow by accident on an empty prompt, landed in agent view, returned to the session. From that moment inbound notifications/claude/channel never renders again. Outbound tools from the same MCP server keep working perfectly, which makes it look like a connectivity problem when it isn't.

Neither available recovery works.

• /mcp reconnect of the channel server — no effect.
• The server's own channel-capture tool — returns success, no effect.
• Only a full Claude Code restart restores delivery.

Mechanism, consistent with the decompilation in #71792: --dangerously-load-development-channels entries are parsed at startup flag-assembly and registered into a per-session channel list, and the inbound gate is kind:"session", looking the server up in that list. A fork creates a new session id without re-running startup flag assembly, so the forked session is never in the list. That is why reconnecting the MCP server cannot help — the block sits at session registration, one layer above the MCP connection.

Why this raises the severity of item 1. The reported cost today is an interruption plus a degraded view. For anyone using channels the real cost is that one accidental keypress silently and permanently severs the inbound event path for that session, with no error surfaced anywhere and no recovery short of restarting. In our case messages from other sessions were queued, flagged as delivered by the sending side, and never seen — silent on both ends.

Requests, in priority order:

1. Re-register development channels on SessionStart when source=fork (covering /branch, /fork, and --fork-session), so a forked session inherits its parent's channel registration.
2. Failing that, expose a way to re-trigger channel registration at runtime — a slash command, or a /mcp action that re-runs registration rather than only reconnecting the transport.
3. On rebindability, I can confirm the original report: there is no documented action id or context for this binding in the keybindings reference, and unbinding left in Footer had no effect here either.

Environment: Claude Code v2.1.228, macOS (Darwin), zsh.

Reproduced on v2.1.233 (macOS).

Steps:

1. Start claude in a project directory, send one prompt and wait for the reply (input box empty afterwards).
2. Press the left arrow key once.

Observed:

• A single unmodified left arrow press immediately backgrounds the conversation and opens the agents screen, with no confirmation (the confirmation Press ← again to open agents only appears if the press comes within a couple of seconds of deleting text or moving through prompt history).
• Pressing Esc (or Enter on the row) brings the conversation back, but it now runs as an attached background session: the input box border shows the session's auto-generated title, and Ctrl+C twice detaches back to the agents screen instead of exiting.
• The conversation continues under a new session ID (a second transcript file appears alongside the original one), so claude --resume <original id> no longer contains the later turns.
• The setting that turns this off, ← opens agents (leftArrowOpensAgents) in /config, is not exposed through keybindings.json; setting left to null (or remapping it) in the Footer context has no effect, because footer:previous only navigates the footer items and is unrelated to this shortcut. In an already-attached background session, ← always detaches regardless of the setting.

Expected (per the report): a plain arrow key on an empty prompt should not navigate away without a modifier or confirmation, it should be rebindable/unbindable, and returning should restore the exact prior foreground session.

Assessment: intended today, but the expectation is reasonable and this is a usability problem worth fixing. The docs describe exactly this behavior (https://code.claude.com/docs/en/agent-view, "Switch sessions without leaving the terminal"): a single ← on an empty prompt moves the conversation to the background and opens agent view, and the only off-switch is the leftArrowOpensAgents toggle in /config — not keybindings.json. Two parts of the original report have since been addressed: the task list dropping on return was fixed in v2.1.210, and since v2.1.218 a ← pressed right after editing asks for confirmation, and Esc in agent view returns you to the conversation. What remains: (1) an unmodified ← is still very easy to hit by accident and can't be unbound or remapped through the keybindings system, so a dedicated keybinding action (or a modifier/confirmation on every foreground press) would help; (2) the conversation genuinely becomes a background session with a new session ID, which is why Ctrl+C twice detaches instead of exiting and why resuming the original session ID stops at the point you pressed ← — the docs should say this, and the intended fix path is /config → disable ← opens agents if you never want the shortcut. I could not verify the follow-up reports (stale autocomplete bar, IDE context loss, channel delivery loss, no response after return) in this pass.

🤖 Generated with Claude Code