Transcript view (Ctrl+O) does not respond to scroll keys

Status Fixed / completed
Reported on v2.1.138
Maintainer reply None cached
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-256color inside tmux, also reproduced in plain terminal outside tmux
  • Shell: zsh 5.x

Steps to reproduce

  1. Start claude in any project.
  2. Have at least a few turns of conversation so there's content to scroll.
  3. Press Ctrl+O — the transcript view opens correctly.
  4. 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.
  • /doctor reports no keybinding-related errors.
  • Only customisation in ~/.claude/keybindings.json is in Chat context (space: null, meta+k: voice:pushToTalk) — nothing touching Transcript or Scroll.
  • Possibly a context-mismatch: the docs/keybinding table list scroll actions under Transcript, but the fullscreen transcript view may actually be in the Scroll context (or neither is receiving keys).

Workaround

None found.

View original on GitHub ↗

6 Comments

github-actions[bot] · 3 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/54719

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

davidj4tech · 3 months ago

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:

  • #54719: the transcript view doesn't tail new messages — it's a static snapshot of the conversation at the moment Ctrl+O was pressed. New prompts/responses are invisible until you toggle the view off.
  • This issue (#59633): the transcript view renders content fine, but the documented scroll keys (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.

adtendo · 2 months ago

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 — /tui reports "Background sessions always use the fullscreen renderer so scrolling and mouse work when attached" and CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 is ignored by design. Combined with this bug, that leaves no working scroll path at all in an attached background session:

  1. Main view: mouse wheel scrolls input history instead of chat scrollback (#12953)
  2. Transcript view (Ctrl+O): no response to any scroll input — mouse wheel, PgUp/PgDn, and arrow keys all dead (this issue)
  3. Text selection can't extend past the visible screen — the alternate screen has no scrollback buffer in Windows Terminal, so off-screen content is unreachable and uncopyable

For directly-started claude sessions, CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 is 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.

davidj4tech · 2 months ago

Update: this looks resolved as of 2.1.195Ctrl+O followed by the
documented 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.

davidj4tech · 2 months ago

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

joell · 2 months ago

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.

Showing cached comments. Read the full discussion on GitHub ↗