Claude Codeでスクロールバックが消える・スクロールできない原因と対処
Claude Codeでスクロールできない、スクロールバックが消えるときの原因と、CLAUDE_CODE_DISABLE_ALTERNATE_SCREENでの回避策、起動時のレンダラー判定、効かない例外を解説します。
Claude Codeでスクロールできない、履歴が消えるときは、フルスクリーン表示が原因です。まずPgUpとマウスホイールを試し、ダメならCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1でクラシック表示に戻します。
Claude Codeのフルスクリーン表示中に、少し前のメッセージへスクロールしても何も出てこないことがあります。GitHub issue #42670の報告者は、v2.1.89以降のオルタネートスクリーンバッファの描画方式が原因だと書いています。このissueは2026年5月5日にクローズされ、9月22日にロックされましたが、クローズ後の7月29日にも「新しいバージョンでも壊れたままだ」というコメントが付いています。
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1という環境変数で多くの場合は回避できます。ただし根はターミナルエミュレーターごとの描画差にあり、この変数が効かない環境や、そもそも対象外の起動方法もあります。
何が起きているか — フルスクリーン表示でスクロールバックが消える
オルタネートスクリーンバッファとは、vimやlessと同じくターミナルが持つ「別画面」に描画する仕組みです。Claude Codeのフルスクリーンレンダリング(TUI)はこの仕組みを使い、会話を専用の画面に描き直します。公式ドキュメントも、会話はターミナルのスクロールバックではなくオルタネートスクリーンバッファの中にあるため、Cmd+Fやtmuxの検索では見えないと説明しています。
issueの報告者はv2.1.90・Apple Terminal環境で、マウスホイールを回しても画面上部の履歴が一切出てこないと書いています。トランスクリプトモード(Ctrl+O)を開いても、提出当時(2026年4月)はCtrl+E(すべて展開)とq(終了)しか機能しなかったとのことです。報告者が「ドキュメントにある」とした書き出しキーとエディタで開くキーは、その環境では動きませんでした。
コメント欄にはmacOSのTerminal.app・iTerm2・Ghostty・Warp、WindowsのWSL2、Linux SSHと、幅広い環境からの追随報告が並びます。特定のターミナルアプリに限った不具合ではなく、フルスクリーンレンダリングを使うと共通して起きる症状だとわかります。Windows 10では別にホイールが矢印キーになる症状もあり、原因と回避策を別記事にしています。
自分はどちらのレンダラーで動いているか
症状が出るのはフルスクリーン側だけなので、最初に起動時のレンダラーを確かめます。/tuiを引数なしで実行すると、いま使っているレンダラーが表示されます。公式ドキュメントによると、起動時のレンダラーは次の順に判定され、最初に当てはまった行で決まります。なお、スクリーンリーダーモードのセッションは常にクラシックです。
起動時のレンダラーが決まる順序
- 1
環境変数でクラシックを指定している
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1かCLAUDE_CODE_NO_FLICKER=0があればクラシックです。前者はtui設定とCLAUDE_CODE_NO_FLICKERより優先されます。 - 2
NO_FLICKER=1を指定している
フルスクリーンで起動します。失敗した起動のあとでも、この変数があればフルスクリーンを試みます。
- 3
失敗した起動の記録、tmux -CC、保存済みのtui設定
直近でフルスクリーンの起動に失敗した場合、iTerm2の
tmux -CC、WindowsへのSSHはクラシックです。そのあとに保存済みのtui設定が続きます。 - 4
初回利用の時期と通信経路
どれにも当たらないときは初回利用の時期で決まります。フラグを取得できる環境では、2026年5月6日以降に初めて使った場合にフルスクリーンです。フラグを取得しない環境でこのマシンに提案ダイアログが出なくなっていればクラシックで、どれにも当たらない場合もクラシックです。
読者がフルスクリーンに「切り替えた覚えがない」のは、4番目の行があるからです。issue本文は「Claude Codeがオルタネートスクリーンに切り替わった」と書いていますが、報告者がどの経路でフルスクリーンに入ったかは本文からは分かりません。v2.1.89では、この描画は環境変数で任意に有効にするものでした。
Bedrock・Vertex・Foundry経由やテレメトリーをオフにした環境は、フラグを取得しない扱いです。この環境でも、初回起動がv2.1.239以降ならフルスクリーンで始まります。
いつから起きているか — 経緯を時系列で追う
公式changelogでは、v2.1.89でちらつきを抑えるCLAUDE_CODE_NO_FLICKER=1が追加されています。仮想化スクロールバック付きの新しいオルタネートスクリーンレンダリングを、任意で有効にする変数でした。issue #42670はその翌日に立っています。
フルスクリーン描画とスクロールバック問題の流れ
- 2026-04-01v2.1.89
CLAUDE_CODE_NO_FLICKER=1が追加される。 - 2026-04-02issue #42670が立つ
同日にgithub-actions botが3件の類似issueを挙げ、3日後に重複として自動クローズすると予告しました。
- 2026-05-05issueがクローズ
GitHubの記録では人の手によるクローズで、理由は「completed」です。
- 2026-05-06v2.1.132
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1が追加される。GitHubのリリース日はUTCでこの日付です。 - 2026-07-14v2.1.210
DISABLE_ALTERNATE_SCREEN=1の使用中にエージェントビューから戻るとゴーストフレームが残る問題を修正。 - 2026-08-21v2.1.239
Bedrock・Vertex・Foundryなどにも、フルスクリーンの一度きりの提案が広がる。
- 2026-09-28v2.1.284
トランスクリプトモードの
[で、セッションより上のターミナル出力が消える問題を修正(macOSとLinux)。
issueの自動クローズ予告は同日に出ていますが、実際にクローズされたのは33日後の5月5日です。本文は同じ根本原因を持つ未解決issueを「12件以上」としており、11件の番号が列挙されています。クローズは「修正が入った」の意味とは限りません。実際、クローズ後にも報告は続いています。2026年5月11日にはv2.1.138使用者が「まだ同じ問題がある」と書いています。5月12日にはmacOSのWarp環境(v2.1.126)から、6月25日にはv2.1.191から新しいパターンの報告が付きました。
issueは2026年9月22日に自動でロックされています。同じ症状に当たった人は、新しいissueを立て、#42670を参照する形が案内されています。
今すぐ試せる対処 — 環境変数と状況別の使い分け
最も確実なのはCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1です。会話をターミナルのネイティブなスクロールバックに残し、Cmd+Fやtmuxのコピーモードもふつうに使えます。
export CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1恒久的に使うなら、~/.zshrcや~/.bashrcなどシェルの初期化ファイルに追記してください。公式のenv-varsページによれば、この変数はCLAUDE_CODE_NO_FLICKERやtui設定より優先されます。
似た効果の手段が2つあるので、違いを並べます。
環境変数と /tui default の違い
DISABLE_ALTERNATE_SCREEN=1
シェルに設定した間は毎回クラシックで起動します。保存済みのtui設定がフルスクリーンでも上書きされ、どのターミナルで開いても同じ結果になります。
/tui default
実行するとtui設定が保存され、クラシックレンダラーに切り替わります。再起動した側のプロセスからは、CLAUDE_CODE_NO_FLICKERが取り除かれます。
状況別の対応は次のとおりです。
| 状況 | 対処 | 補足 |
|---|---|---|
| とにかく過去の会話を遡りたい | 対処CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 | 補足クラシックレンダラーに戻る |
| 設定として恒久的にクラシックへ戻したい | 対処/tui default | 補足tui設定として保存される |
| いまのセッションだけ一時的に見たい | 対処Ctrl+Oでトランスクリプトモード→[ | 補足Escかqで抜けるとフルスクリーンに戻る |
| tmuxを併用している | 対処通常のtmux。ホイールにはmouse onが必要 | 補足iTerm2のtmux -CCでは最初からクラシック |
| 古い設定のまま困っていない | 対処対応不要 | 補足クラシックのままなら影響しない |
Ctrl+Oのトランスクリプトモードで[を押すと、ツール出力を全展開した会話全体がネイティブスクロールバックへ書き出されます。長いセッションでは少し待たされることがあります。操作の詳細はClaude CodeのCtrl+Oトランスクリプトビューアーの使い方にまとめています。フルスクリーンレンダリングの仕組み自体はClaude CodeのTUI(フルスクリーン)とは、tmux併用時の注意点はClaude Code tmux設定を参照してください。
スクロールできないときの確認順
フルスクリーン表示のスクロールは、ターミナルではなくClaude Code自身が処理します。マウスホイールが効かないときは、先にキー操作で動くかを見ます。
PgUpとPgDnで半画面ずつ動く。MacBookのキーボードではFn+↑とFn+↓が使えます- ホイールだけ動かないなら、ターミナルがマウスイベントを渡していません。iTerm2はプロファイルの「Enable mouse reporting」をオンにします
- ホイールが遅いだけなら、
CLAUDE_CODE_SCROLL_SPEEDで移動量を増やせます - 上へ遡るとオートフォローが止まります。最下部に戻るには
Ctrl+Endか、画面下の「Jump to bottom」を使います。MacではCtrl+Endが届かないため、ボタンのクリックかFn+↓で戻ります
どれも効かず、過去の会話そのものが見えないなら、前の節のCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1でクラシック表示に戻します。
この環境変数が効かない場面
公式ドキュメントには、環境変数が効かない例外が1つ書かれています。agent viewから開いたバックグラウンドセッションとclaude attachは、常にフルスクリーンで描画されます。tui設定もCLAUDE_CODE_DISABLE_ALTERNATE_SCREENも、ここには適用されません。クラシックレンダラーにはこの接続に必要なスクロールバックやマウス処理が無いから、という理由です。
2026年6月25日のissueコメントは、1セッションで多数のサブエージェントを動かしたときのスクロールバックの途切れを報告しています。これがバックグラウンドセッションの話なのか、通常のセッション内のサブエージェントなのかは、コメントの文面からは判別できません。切り分けるなら、まずagent view経由で開いたセッションかどうかを確認します。同じコメントは回避策の1つにCLAUDE_CODE_NO_FLICKER=0を挙げており、これは起動判定でクラシックを指定する値と一致します。
なぜ直りきらないのか — ターミナルエミュレーターごとの描画差
issueのコメント欄では、有志による実測も進んでいます。2026年4月21日、WSL2/Windows 11環境から実測の報告がありました。オルタネートスクリーンへの切り替えシーケンス(1049/1047/47のh/l)自体は検出されなかったといいます。代わりに、CSI 2J(画面全消去)とCSI H(カーソルを先頭へ)の組み合わせが描画のたびに送られていました。CSI 2Jがスクロールバックに触れるかどうかはVT仕様上あいまいで、ConPTYやxterm.jsを含む一部のエミュレーターではスクロールバックを壊す挙動になっている、という分析でした。これはAnthropicの公式見解ではなく、あくまでissue上の検証です。
同じ報告者は4月23日に、逆向きの回避策も書いています。CLAUDE_CODE_NO_FLICKER=1でオルタネートスクリーンに入れてメインバッファのスクロールバックを守り、代わりに奪われたマウスホイールを自作のプロキシで増幅する方法です。ホイール1クリックあたりの移動が約0.2行と遅かったため、イベントを4倍にして実用になったと書かれています。クラシックに戻すのではなくフルスクリーンの側に倒す手もある、という実例です。
同じ環境変数でも、効き方が環境によって揃わないことは、ほかの投稿からもうかがえます。
- 4月3日のGhostty環境の投稿によると、
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1でスクロールバックは戻ります。ただし約300行の内部レンダーバッファ上限は残るとのことです。 - 同じWSL2/Win11の報告は、当時の環境ではこの変数の効果がなかったとも書いています。
- 4月6日のv2.1.90・Terminal.appの投稿では、
CLAUDE_CODE_NO_FLICKER=0を設定済みでした。それでもサブエージェントが現れた直後にスクロールバックが消えたそうです。
公式changelogがCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1の追加を明記したのはv2.1.132です。一方コメント欄では、4月3日の時点ですでに「未文書化のまま動く環境変数」として言及されています。文書化と実装のタイミングがずれていたことになります。
4月23日には、iTerm2環境の利用者から、オルタネートスクリーンの利点を保ちながらメイン画面のスクロールバックにも同時出力する「第3のモード」を求める要望が出ました。5月12日のWarp環境・v2.1.126からの報告は、原因をより明確に言い切っています。フルスクリーンレンダリングはオルタネートスクリーンへ全出力を描き、メイン画面には何も書き込まれないため、スクロールバックに残す対象自体が存在しません。tmuxのコピーモードやPgUp/PgDnでは原理的に復元できない、という説明です。「第3のモード」は、このissueの範囲では実装されていません。
CLAUDE_CODE_DISABLE_ALTERNATE_SCREENは緩和策として使うのが実態に近い
Anthropicが無反応だったわけではありません。ちらつき抑制のNO_FLICKERから、オルタネートスクリーンを無効化できる環境変数、ゴーストフレーム修正、[でターミナル出力が消える問題の修正まで、半年近くかけて選択肢は積み増されています。ただし根本原因とされるCSI 2Jの扱いはターミナルエミュレーター側の実装差に依存します。Claude Code単体のアップデートだけでは閉じ切れない領域が残ります。
実用的な結論は、CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1を「最新版に上げれば直る問題」の代わりに使うことです。バージョンを上げるたびに再発しないか確かめるより、環境変数を先に固定してしまうほうが手数は少なく済みます。
よくあるつまずき
CLAUDE_CODE_NO_FLICKER=0にしてもフルスクリーンから抜けられない
公式ドキュメントの起動判定表では、CLAUDE_CODE_NO_FLICKER=0もクラシックで起動する指定です。それでも変わらない場合は、ほかの要因を疑います。
- 別のシェルや常駐起動で、
NO_FLICKER=1が上書きされている - agent viewから開いたバックグラウンドセッションを見ている
/tuiの出力で、現在のレンダラーと、失敗した起動が理由かどうかを確認する
NO_FLICKER=1がどこかで設定されているなら、まずシェルの環境変数から外します。そのうえで確実なのはCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1で、tui設定とNO_FLICKERのどちらより優先されます。/tui defaultは保存設定なので、NO_FLICKER=1が残っていると次の起動で上書きされます。
環境変数を設定したのに変わらない
exportした後に、その設定が今使っているシェルセッションへ反映されているか確認してください。~/.zshrcなどに書いた場合は、新しいターミナルタブを開くかsourceし直す必要があります。
[を押したら画面の上のログが消えた
v2.1.284より前では、トランスクリプトモードの[で書き出すと、セッションより上にあったターミナル出力が消える不具合がありました(macOSとLinux)。v2.1.284で修正されています。それ以前のバージョンを使っているなら、アップデートが先です。
tmuxで期待どおりに動かない
tmux内でもフルスクリーンは動きますが、ホイールスクロールにはtmuxのmouse modeが必要です。~/.tmux.confにset -g mouse onを足します。mouse modeが無いとホイールはClaude Codeでなくtmuxへ届き、PgUpとPgDnのキー操作だけが使えます。Zellijでスクロール後に入力できなくなる報告は、Zellijで入力できない件の切り分けにまとめています。
iTerm2のtmux -CCでは、オルタネートスクリーンバッファとマウス追跡がうまく働かず、ホイールが反応しない、ダブルクリックで端末の状態が壊れうると公式は説明しています。この環境では最初からクラシックで起動するので、フルスクリーンを有効にしないでください。
まとめ
症状が出たら、まず/tuiで現在のレンダラーを確認します。フルスクリーンだったなら、CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1で会話をネイティブなスクロールバックへ戻すのが最短です。agent viewのバックグラウンドセッションは、この変数が効かない例外です。Claude Codeの設定全体はClaude Code完全ガイドにまとまっています。KDE KonsoleでShift+PageUpだけが効かない場合は別の原因なので、Konsoleでのスクロール・コピー・再描画の不具合を参照してください。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。