You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tried to reproduce this and traced the keyboard path end-to-end; couldn't find a code path in the desktop app that swallows plain Ctrl+B.
What I checked:
Hotkey registry (apps/desktop/src/renderer/hotkeys/registry.ts) — TOGGLE_WORKSPACE_SIDEBAR is bound to meta+b on macOS and ctrl+shift+b on Windows/Linux. Plain ctrl+b is not a registered chord on any platform.
Terminal key event handler (apps/desktop/src/renderer/lib/terminal/terminal-key-event-handler.ts) — resolveHotkeyFromEvent returns null for unregistered chords, and the handler then returns true (passes the event to xterm) for Ctrl+B. None of the line-edit / select-all / clipboard branches match it either.
xterm encoder (@xterm/xterm v6, with vtExtensions: { kittyKeyboard: true }) — kitty mode is gated on flags > 0, and the flags only become non-zero when an application sends CSI > N u. By default the legacy encoder runs, which encodes Ctrl+B (keyCode 66) as String.fromCharCode(66 - 64) = \x02. That's exactly the byte Claude Code expects for background mode.
PTY forwarding — xterm.onData is wired to handleTerminalInput in useTerminalLifecycle.ts (and to the WS transport in v2), which calls writeRef.current({ paneId, data }) to forward bytes to the PTY.
I also wrote a quick repro test that fired a Ctrl+BKeyboardEvent through createTerminalKeyEventHandler on MacIntel / Win32 / Linux x86_64 — the handler returned true (no swallow) on all three, and didn't call preventDefault or xterm.input. So the chord reaches xterm's encoder, which sends \x02 to the PTY.
A few possibilities that would explain the symptom outside this codebase:
A multiplexer between Superset and Claude Code — tmux uses Ctrl+B as its prefix key by default, so if Claude Code is running inside tmux, tmux eats it. screen (Ctrl+A prefix), zellij, etc. can do similar things.
A user hotkey override binding something to ctrl+b in Settings → Keyboard. The override store would put ctrl+b in registeredAppChords, which would make the terminal handler swallow it.
A different chord than I'm assuming — could you confirm whether you're pressing literal Ctrl+B (the Control key) or Cmd+B on macOS? Cmd+Bis bound to Toggle Workspaces Sidebar on macOS, which would intercept it.
If you can share platform (macOS / Windows / Linux), whether anything is wrapping the shell (tmux/screen/etc.), and whether you've customized hotkeys in Settings → Keyboard, I'm happy to dig further.
Closing as a duplicate of #5604, the consolidated tracker for stale terminal-input issues from the July 2026 stale-issue sweep (no activity since 2026-06-01). If this still applies on a current build, comment on #5604 and we'll reopen.
Activity
github-actions commentedon May 2, 2026
Tried to reproduce this and traced the keyboard path end-to-end; couldn't find a code path in the desktop app that swallows plain
Ctrl+B.What I checked:
apps/desktop/src/renderer/hotkeys/registry.ts) —TOGGLE_WORKSPACE_SIDEBARis bound tometa+bon macOS andctrl+shift+bon Windows/Linux. Plainctrl+bis not a registered chord on any platform.apps/desktop/src/renderer/lib/terminal/terminal-key-event-handler.ts) —resolveHotkeyFromEventreturnsnullfor unregistered chords, and the handler then returnstrue(passes the event to xterm) forCtrl+B. None of the line-edit / select-all / clipboard branches match it either.@xterm/xtermv6, withvtExtensions: { kittyKeyboard: true }) — kitty mode is gated onflags > 0, and the flags only become non-zero when an application sendsCSI > N u. By default the legacy encoder runs, which encodesCtrl+B(keyCode 66) asString.fromCharCode(66 - 64)=\x02. That's exactly the byte Claude Code expects for background mode.xterm.onDatais wired tohandleTerminalInputinuseTerminalLifecycle.ts(and to the WS transport in v2), which callswriteRef.current({ paneId, data })to forward bytes to the PTY.I also wrote a quick repro test that fired a
Ctrl+BKeyboardEventthroughcreateTerminalKeyEventHandleronMacIntel/Win32/Linux x86_64— the handler returnedtrue(no swallow) on all three, and didn't callpreventDefaultorxterm.input. So the chord reaches xterm's encoder, which sends\x02to the PTY.A few possibilities that would explain the symptom outside this codebase:
Ctrl+Bas its prefix key by default, so if Claude Code is running inside tmux, tmux eats it.screen(Ctrl+Aprefix),zellij, etc. can do similar things.ctrl+bin Settings → Keyboard. The override store would putctrl+binregisteredAppChords, which would make the terminal handler swallow it.Ctrl+B(the Control key) orCmd+Bon macOS?Cmd+Bis bound to Toggle Workspaces Sidebar on macOS, which would intercept it.If you can share platform (macOS / Windows / Linux), whether anything is wrapping the shell (tmux/screen/etc.), and whether you've customized hotkeys in Settings → Keyboard, I'm happy to dig further.
Kitenite commentedon May 2, 2026
HI i can't reproduce ctrl+b in ghostty for background claude code could you share claude version?
Kitenite commentedon Jul 11, 2026
Closing as a duplicate of #5604, the consolidated tracker for stale
terminal-inputissues from the July 2026 stale-issue sweep (no activity since 2026-06-01). If this still applies on a current build, comment on #5604 and we'll reopen.