[BUG] Agent View background-session input: Ctrl+b does nothing on 1st press, moves cursor back 2 characters on 2nd press

Summary

In Agent View (opened via claude agents), after attaching to any background session, the chat input inside that session handles Ctrl+b incorrectly:

• 1st press — no visible effect (input event is swallowed).
• 2nd press — cursor moves backward two characters on a single press.

Expected: each Ctrl+b moves the cursor back one character (Emacs-style backward-char), matching foreground claude.

The problem occurs only in the per-session chat input inside Agent View — not in the Agent View session-list screen, and not in foreground claude.

Only Ctrl+b misbehaves. Ctrl+f, Ctrl+a, Ctrl+e, Ctrl+d, Alt+b, and Alt+f all work correctly in the same input field.

Environment

Claude Code: reproduced on 2.1.211, 2.1.212, 2.1.214 (all latest channel).

Linux:

• OS: Ubuntu 24.04
• Install: native ELF SEA (~/.local/share/claude/versions/<version>)
• Terminals tested: Tabby (xterm.js), Konsole (Qt), qterminal — all reproduce
• tmux 3.7b (as reported by XTVERSION): reproduces both inside tmux (with prefix remapped to C-t and C-b unbound) and directly on the terminal
• IME: fcitx5 with/without active preedit — no difference

Windows:

• OS: Windows 11
• Install: native win32-x64
• Terminal: Windows Terminal (default) — reproduces

Reproduction

1. claude agents
2. If the session list is empty, type any prompt into the input at the bottom of Agent View and press Enter to create a new background session. Otherwise, use ↑/↓ to select a session row and press Enter (or →) to attach.
3. In the chat input inside the session, type abcdef. Cursor (shown as |) at end:

``
> abcdef|
``

1. Press Ctrl+b (1st press). No visible change — cursor stays at end:

``
> abcdef|
``

1. Press Ctrl+b (2nd press). Cursor jumps back two characters on a single press:

``
> abcd|ef
``

Expected after step 5 would be abcde|f (one character back from step 4), not two.

Reproduces regardless of the interval between the two presses (tested at 0.2 s, 1 s, 3 s+ — so this is not a chord-timeout effect). Reproduces on both freshly-created and resumed sessions.

Does not reproduce in foreground claude, and does not reproduce in the Agent View session-list screen — only inside a per-session chat input.

Diagnosis performed

To narrow the responsible layer, I overrode the Task context in ~/.claude/keybindings.json to unbind every Ctrl+b-related binding reachable from the keybindings config:

{
  "context": "Task",
  "bindings": {
    "ctrl+b": null,
    "ctrl+x ctrl+b": null,
    "ctrl+b ctrl+b": null
  }
}

--debug output confirms the file loads ([keybindings] Loaded 154 user bindings, no validation error), but the symptom is unchanged. This rules out the documented Task context and its task:background binding as the cause, and points to an interception outside the keybindings layer — likely inside the background-session input handler.

Investigation notes

Extracted from strings on the 2.1.214 Linux binary:

• Hardcoded press-twice hints: ctrl+b ctrl+b (twice), Ctrl+B/F, help text (press prefix twice - Claude uses …).
• Docs page https://code.claude.com/docs/en/keybindings already flags: _"Ctrl+B: tmux prefix (press twice to send)."_ — implying an intentional press-twice escape to coexist with the tmux prefix.
• Chord machinery is present in the binary (constant CHORD_TIMEOUT_MS, functions chord_started / setPendingChord / isChordCompletion, log line [keybindings] Chord timeout - cancelling), but this behavior is not chord-driven: interval-independent, and Task-context unbinding of ctrl+b ctrl+b has no effect.
• Valid contexts enumerated by the runtime (from a --debug invalid-context warning): Global, Chat, Autocomplete, Confirmation, Help, Transcript, HistorySearch, Task, ThemePicker, Settings, Tabs, Attachments, Footer, MessageSelector, DiffDialog, DiffPanel, ModelPicker, Select, Plugin, Scroll. No user-overridable context is specific to Agent View sessions.

Best guess: the press-twice logic is hardcoded in the background-session input path (Ink readline emulation or the PTY-bridged input layer). On the "second press confirmed" branch it delivers both the queued 1st keystroke and the current 2nd keystroke to the readline buffer at once, producing a 2-character backward jump. Meanwhile foreground claude does not use this same input path and behaves correctly.

Related issues

• #22315 — _"Ctrl-B cursor movement stops working after using Ctrl-R or Ctrl-G"_. Marked fixed in 2.1.83; this may be a regression via a different code path (the background-session input) rather than a re-open of the same bug.
• #68465 — _"Windows: agent/background-session TUI prints raw un-framed ANSI (dropped ESC) AND cross-session input bleed"_. Different symptom, same subsystem (Agent View background sessions).
• #66398 — _"cursor not visible in typing window on first session attach"_. Adjacent input-layer issue.
• #69973 — _"Ctrl+B (background command) does nothing during the 'thinking' phase"_. Implies Ctrl+b reaches a task:background handler in some session states — possibly the same code path.

Expected fix

Ctrl+b should move the cursor back one character per press, matching foreground claude.