Transcript view (Ctrl+O) does not respond to scroll keys
Status Fixed / completed
Reported on v2.1.138
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 7 comments · opened May 16, 2026 · closed Jun 27, 2026
Summary
After opening the transcript view with Ctrl+O (app:toggleTranscript), none of the documented scroll keys respond — keyboard input appears to be ignored entirely. Reproduces both inside and outside tmux.
Environment
- Claude Code: 2.1.138 (native install)
- OS: Linux (proot-distro under Termux on Android),
TERM=tmux-256colorinside tmux, also reproduced in plain terminal outside tmux - Shell: zsh 5.x
Steps to reproduce
- Start
claudein any project. - Have at least a few turns of conversation so there's content to scroll.
- Press
Ctrl+O— the transcript view opens correctly. - Press any of:
j,k,Up,Down,Ctrl+U,Ctrl+D,Ctrl+B,Ctrl+F,g,G,Home,End.
Expected
The transcript scrolls per the documented Transcript / Scroll context bindings (scroll:lineUp, scroll:halfPageUp, etc.).
Actual
No response to any of those keys. View stays put. Esc / q / Ctrl+C do close the view, so some keys reach it — only the scroll keys are unresponsive.
Notes
- Reproduces outside tmux, so this is not a terminal-multiplexer/key-passthrough issue.
/doctorreports no keybinding-related errors.- Only customisation in
~/.claude/keybindings.jsonis inChatcontext (space: null,meta+k: voice:pushToTalk) — nothing touchingTranscriptorScroll. - Possibly a context-mismatch: the docs/keybinding table list scroll actions under
Transcript, but the fullscreen transcript view may actually be in theScrollcontext (or neither is receiving keys).
Workaround
None found.
Showing cached comments. Read the full discussion on GitHub ↗
6 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Thanks for the pointer, but I don't think #54719 is the same bug — they share the transcript view as a surface but the underlying issue is different:
Ctrl+Owas pressed. New prompts/responses are invisible until you toggle the view off.j/k, arrows,Ctrl+U/Ctrl+D,g/G,Home/End,PageUp/PageDown) do nothing — there's no way to scroll back through the visible transcript from inside the view itself.#54719 does mention in passing that "the current input prompt also seems to swallow keystrokes for viewer navigation," but that's a side note in a bug primarily about content-tailing. Here scroll-key navigation is the bug.
Exit keys (
Esc,q,Ctrl+C) do reach the view and close it, so some keys are delivered — just not the scroll ones. Reproduces both inside and outside tmux.Happy to provide additional diagnostics if useful.
Reproduced on v2.1.168, WSL2 + Windows Terminal, with an aggravating factor for attached background sessions (
claude agents/ FleetView):Background sessions force the fullscreen renderer —
/tuireports "Background sessions always use the fullscreen renderer so scrolling and mouse work when attached" andCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1is ignored by design. Combined with this bug, that leaves no working scroll path at all in an attached background session:For directly-started
claudesessions,CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1is a viable workaround (inline renderer + native terminal scrollback). For background sessions there is no opt-out, so the stated rationale ("so scrolling and mouse work when attached") currently doesn't hold — at minimum on Windows Terminal. Suggest either fixing transcript-view key handling for attached sessions or honoring the alternate-screen opt-out there too.Update: this looks resolved as of 2.1.195 —
Ctrl+Ofollowed by thedocumented scroll keys (
j/k, arrows,Ctrl+U/Ctrl+D,g/G,Home/End,PageUp/PageDown) now scrolls the transcript view as expected,both inside and outside tmux.
I couldn't pin an explicit changelog line for the keyboard-scroll fix between
2.1.138 and 2.1.195 — that range has several transcript/scroll fixes, but mostly
mouse-wheel and subagent-transcript ones — so I'm unsure exactly which release
landed it, but it's working now.
@adtendo — does it also scroll for you on a current build, including the attached
background-session / FleetView case you flagged? If that fullscreen-renderer
scenario still swallows the keys, that's probably worth a separate, narrower
issue rather than holding this one open.
Closing as resolved — thanks for the dup-triage and the extra repro.
Filed a narrow follow-up for the case that remains after this was resolved for inline sessions: the forced-fullscreen renderer (attached background/child sessions) still doesn't respond to keyboard scroll keys in the Ctrl+O transcript — #71749. cc @adtendo
For what it's worth, this is still broken for me in 2.1.195. I'm on Linux, not using tmux, and this issue persists for me on Gnome Terminal, wezterm, and alacritty. After hitting Ctrl+O, none of j/k, Ctrl+U/Ctrl+D, nor PageUp/PageDown will scroll the transcript. Only the terminal scrollback buffer works... up to a certain limit after which the scrollback is corrupted with overwrites.
I'd suggest this issue be reopened.