[BUG] Fullscreen TUI: left arrow backgrounds the tab and kills subagents, twice exits without confirmation; keybindings.json overrides don't suppress it

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 1 comment · opened Aug 5, 2026

Summary

With "tui": "fullscreen", arrow-key navigation in the tab strip is destructive and unguarded, and it cannot be disabled via keybindings.json.

Version: 2.1.221
Platform: macOS 15.6 (iTerm2). Also reproduced on Linux (arm64) over ssh + zellij.

Behavior

  1. Press left once — the current tab is backgrounded and any running subagents or workflows in it are killed. No prompt, no warning.
  2. Press left twice — Claude Code exits entirely, killing every session. No confirmation.

Neither is recoverable, and neither announces itself before acting. Losing in-flight subagent work to a single stray arrow key is easy to do while editing a prompt.

Overrides are accepted but have no effect

This ~/.claude/keybindings.json does not change the behavior:

{ "context": "Footer", "bindings": { "left": null, "right": null } },
{ "context": "Tabs",   "bindings": { "left": null, "right": null } }

claude --debug keybindings reports the file loading cleanly:

[keybindings] Loaded 7 user bindings
KeybindingSetup initialized with 196 bindings, 0 warnings

So the nulls are parsed and accepted, but the tab strip still responds to left/right. That suggests the tab strip handles the key ahead of the keybinding registry rather than through it.

Workaround

Setting "tui": "default" avoids it — no tab strip — but that means giving up the fullscreen renderer to work around a keybinding.

Asks, in priority order

  1. Confirm before an action that kills running subagents, and before exiting with live sessions.
  2. Make Tabs/Footer null overrides actually suppress tab-strip arrow navigation — or document which context owns those keys.

Notes

  • I did not isolate whether the one-press and two-press behaviors share a code path.
  • The --debug keybindings output above is from a slightly earlier 2.1.x build; the destructive behavior itself is confirmed on 2.1.221.
  • Possibly related: #64804 (keybindings.json override ignored for a different key).

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗