TUI scroll buffer limited to ~10 lines when viewing running session
Description
When using the Claude Agents feature and entering a running agent session, scrolling up in the conversation view is limited to approximately 10 lines. You cannot scroll back further to see earlier conversation history within the TUI.
This issue is specific to the agents workflow — starting a new interactive session does not reproduce it. It only occurs when hopping into an already-running agent session from the session list.
Steps to Reproduce
- Start a Claude Code agent session (background task)
- From the session list, enter the running agent session
- Attempt to scroll up through the conversation
Expected Behavior
Should be able to scroll back through the full (or a reasonably large) conversation history within the TUI, similar to how other terminal-based chat tools behave.
Actual Behavior
Scroll is capped at ~10 lines. Earlier conversation content is inaccessible from within the TUI.
Environment
- Terminal: iTerm2 (version 3.6.10)
- Platform: macOS
- iTerm2 settings checked: "Save lines to scrollback in alternate screen mode" and "Save lines to scrollback when an app status bar is present" — both enabled, no effect
- Session logging enabled — also no effect on in-session scroll
Additional Context
This appears to be a Claude Code TUI render buffer limitation rather than a terminal emulator issue — the TUI owns the scroll region and limits how far up you can go. The full conversation is accessible via claude.ai/code in the browser, but not from within the CLI session view.
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This has only occured when using
claude agentsand going into a running session, or stopped session and scrolling up. Regular claude code sessions TUI work fine when scrolling back.This isn't a duplicate of #28077 or of #42002. I can't determine if it is a duplicate of #53193. In any case, I am having the same problem as @michaelsc44 . The problem is that I cannot scroll back through past output in agent mode when running inside GNU screen over SSH. Description is below, report generated from discussion with a Claude session.
Environment
Summary
When Claude Code is running an agent task ("agent mode"), there is no working way to scroll back through earlier output of the current turn. The relevant content is on-screen but past the visible region,
and none of the usual scrollback mechanisms work:
correctly when Claude is in regular (non-agent) mode in the same screen session, so the difference is between the two Claude modes, not a screen configuration issue.
Net effect: once output scrolls past the top of the pane during an agent turn, it is unrecoverable.
Steps to reproduce
Expected behavior
Either:
Actual behavior
Agent-mode output is unreachable once it scrolls off-screen. The same screen copy-mode sequence that works for regular Claude output produces an empty/limited buffer for agent-mode output, suggesting the
agent UI uses the alternate screen buffer (or otherwise bypasses the host terminal's line history) in a way the non-agent mode does not.
Workarounds tried
Impact
On a remote SSH workflow this is a blocker for any longer agent response — multi-step instructions, diagnostic checklists, or code review output frequently exceed one pane, and the user has no way to
re-read what was produced earlier in the same turn without re-prompting.
Okay I got this working after poking around some more in iTerm2. It's actually the mouse reporting that was causing this issue. Claude's TUI runs in the alternate screen buffer and manages its own internal scrollback. Without mouse reporting enabled, iTerm2 intercepted scrollwheel events and tried to scroll its own scrollback buffer, which doesn't contain alt-screen content, so it appeared cut off. PageUp/PageDown buttons on my keyboard worked because those keys were passed through to claude. Enabling mouse reporting in iTerm2's settings forwards scroll events to claude, which can then scroll through its full session history.
<img width="988" height="646" alt="Image" src="https://github.com/user-attachments/assets/514c5a8e-0b4e-4878-be37-3318b853eed2" />
Thanks for the update, @michaelsc44. That fixed it for me, too! I disabled this feature due to all the alerts, so glad that we happened to be using the same terminal.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.