「Cannot switch renderers in this session」の意味と対処法

/tui fullscreenや/tui defaultでレンダラーを切り替えようとしたのに、次のメッセージが出て何も変わらないことがあります。

Cannot switch renderers in this session — it has restrictions a restart can't carry over (permission rules set for this session only). Nothing was changed. Running /tui fullscreen in a session started without them switches every later session too.

/tuiは会話を保持したままプロセスを再起動する処理で、このメッセージは再起動先のプロセスに引き継げない制約がそのセッションにあるときに出ます。括弧内の文言が原因を名指ししており、4パターンに分かれます。原因ごとの見分け方と、フルスクリーン表示を使うための回避策を扱います。

「Cannot switch renderers in this session」はなぜ出るのか

/tui fullscreenと/tui defaultは、見た目としては表示モードの切り替えですが、内部では現在の会話を保持したままプロセスを再起動する処理です。再起動後の新しいプロセスに引き継げない制約がセッションに掛かっていると、Claude Codeは再起動を拒否し、切り替えもtui設定の保存も行いません。

このエラーには、文言の違う兄弟がいます。次の2つは出る理由も対処も別物です。

表示された文言のどちらかひとつだけが拒否の理由です。以降は「in this session」の方を扱います。

フルスクリーン表示は、ちらつきを抑え、長い会話でもメモリ使用量を平らに保つレンダラーで、リサーチプレビューの位置づけです。差が出やすいのは、VS Codeの統合ターミナル・tmux・iTerm2のように、描画の処理量が詰まりやすい端末です。画面上端へスクロール位置が飛ぶ、ツール出力が流れるたびに画面が光る、といった症状が気になる場合に切り替える対象になります。ウィンドウを最大化する機能ではなく、vimのように端末の描画面を占有する方式を指します。

v2.1.234で何が変わったのか

v2.1.234(2026年8月17日)より前は、この確認自体がありませんでした。制約があっても構わず再起動し、再起動後のセッションは制約なしで動いていました。起動時に付けた--allowed-toolsや--disallowed-toolsのルールが、/tuiを経由すると外れていたことになります。

changelogには同じ版の修正が2件並んでいます。1つは、起動時の--allowed-toolsと--disallowed-toolsが/tuiで落ちる問題です。再起動を断り、理由を表示する挙動に変わりました。もう1つは、起動時に出る「Try the new fullscreen renderer?」の提案を受け入れたときの問題です。権限モード(--dangerously-skip-permissionsなど)やツールの許可・拒否ルール、モデルやeffortの指定が引き継がれませんでした。

つまりこの拒否は、利便性を削る変更ではありません。表示を変えただけのつもりで権限のガードが外れる事態を、黙って起きる状態から理由つきで止まる状態へ変えたものです。

括弧内の文言が示す4つの原因

エラーメッセージの括弧内には、該当した制約の種類がそのまま書かれます。

共通点は、いずれも起動時のコマンドラインに戻せない設定だということです。新しいプロセスはコマンドラインと設定ファイルから組み立て直すため、実行中のメモリにしかない動的なルールは再現できません。

2行目には例外があります。session宛てのallowルールは拒否の引き金になりません。再起動で消え、Claude Codeがあらためて承認を求めます。止まるのは、消えると拒否や確認の制約が外れてしまうルールの場合です。

起動フラグが原因のとき: 実機で確かめられること

1行目の原因は、自分で付けたフラグなので突き止めやすいものです。v2.1.289のclaude --helpで、該当するフラグは次のように並んでいます。

claude --help | grep -E -- "^  --(system-prompt|tools|setting-sources) "

  --setting-sources <sources>           Comma-separated list of setting sources
  --system-prompt <prompt>              System prompt to use for the session
  --tools <tools...>                    Specify the list of available tools from

エイリアスやラッパースクリプトが、これらを自動で付けている場合もあります。シェルでtype claudeを実行すると、claudeが素のコマンドなのかエイリアスなのかが分かります。

一方で、--allowed-tools・--disallowed-tools・--agent・--agentsなどは、再起動後のセッションに引き継がれる側です。引き継がれるものは次のとおりです。

同じシステムプロンプトの指定でも扱いが分かれます。--system-promptと--append-system-prompt-fileで起動したセッションは止まり、--append-system-promptなら通ります。フラグ名の末尾が-fileかどうかの違いは見落としやすいところです。

すぐにできる対処

そのセッションの中でできることはありません。制約を持たない新しいセッションを別に起動し、そちらで実行します。

/tui fullscreen

/tui fullscreenはtui設定を保存するので、次回以降のセッションは保存済みの設定でレンダラーを選びます。/tuiを引数なしで実行すると、現在のレンダラーが表示されます。

/tuiを経由せず、起動時にフルスクリーンを指定する方法もあります。

CLAUDE_CODE_NO_FLICKER=1 claude

この環境変数はtui設定より優先され、--system-promptのような制約付きの起動でもフルスクリーンで始まります。再起動を伴わないので、本記事のエラーとは無縁です。フラグを外せない自動化やラッパースクリプトでは、この形が最初に検討する選択肢になります。起動コマンドの手前に変数を置くだけで、そのプロセスにだけ効きます。保存済みのtui設定は書き換わりません。

ただし2つの設定は同格ではありません。CLAUDE_CODE_NO_FLICKER=0かCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1を設定していると、tui設定やNO_FLICKER=1より優先されてクラシック表示になります。両方を設定した場合も、クラシック表示が勝ちます。また/tuiは、再起動したプロセスからCLAUDE_CODE_NO_FLICKERを取り除きます。設定ファイルに書くtuiの値を効かせるためです。CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1を設定している環境では、/tui fullscreenを実行してもクラシック表示のままです。

設定ファイルに書いてしまう方法

tui設定は設定ファイルに直接書けます。値は"fullscreen"か"default"で、置き場所はどの設定ファイルでも構いません。

{
  "tui": "fullscreen"
}

この書き方なら、制約付きのセッションでもエラーは出ません。tui設定を書いても再起動は起きません。ただし現在のセッションのレンダラーは変わらず、次回以降の起動から効きます。起動時にフルスクリーンの提案ダイアログが出た場合も、受け入れると/tui fullscreenと同じ再起動を行い、セッションの状態を引き継ぎます。設定の保存は、再起動後のセッションが正常に起動してからです。

agent viewから開いてアタッチしたバックグラウンドセッションは、tui設定に関係なく常にフルスクリーンで描画されます。

原因を作っている側ごとの恒久対応

制約を外すかどうかは、制約を付けた側が決めることです。

フックやSDKが入れているのは、そのセッションだけ有効なガードです。表示の快適さのために個人の判断で外すと、別の場面でもガードを失います。制約付きのセッションでクラシックレンダラーを使い続けると、ちらつきの軽減・メモリ使用量の抑制・マウス操作は使えません。会話の機能そのものは変わりません。

フルスクリーンに切り替わらないとき、このエラー以外の原因もあります。tmuxの-CCモードや、Windowsへ入るSSH接続では、CLAUDE_CODE_NO_FLICKER=1を指定しない限りクラシックレンダラーが維持されます。フルスクリーンのセッションが起動を完了せずに落ちた場合は、その直後のセッションがクラシックで始まります。その状態かどうかは、/tuiの引数なし実行で出るCurrent rendererの行で分かります。

よくある質問

スクリーンリーダーモードでも同じメッセージが出ますか

出ません。スクリーンリーダーモードでは、アタッチしたバックグラウンドセッションを除いて常にクラシックレンダラーが使われます。/tui fullscreenを実行すると別の説明メッセージが表示され、tui設定は変更されません。

Desktopアプリでも出ますか

公式のエラー一覧は、コマンドライン系のエラーをCLI・Desktopアプリ・クラウドセッションに共通のものとして扱っています。Desktopアプリとクラウドセッションも内部で同じCLIを動かしているため、/tuiを実行すれば同じ条件で出ます。

制約付きかどうかを事前に調べる方法はありますか

起動フラグが原因なら、起動コマンドを見れば分かります。フックやSDKが途中で足したルールは、/tuiを実行して拒否されるまで気付きにくいものです。心当たりがなければ、フック設定とSDKの呼び出しコードでsession宛ての権限更新を探します。

バックグラウンド側のメッセージは、いつから出るようになりましたか

v2.1.141からです。それ以前の/tuiは、動いているバックグラウンドのシェルやサブエージェントを黙って落としていました。v2.1.273では、作業を終えて一覧から消えたエージェントチームの仲間を理由に拒否される不具合が直っています。

まとめ

「in this session」の拒否は、起動フラグかセッション限定の権限ルールのどちらかが原因で、括弧内を読めば特定できます。制約のない新しいセッションで切り替えるか、起動コマンドにCLAUDE_CODE_NO_FLICKER=1を加える2通りで済みます。起動フラグを外せない自動化なら後者、手作業のセッションなら前者が手軽です。

フルスクリーン表示の仕組みやマウス操作、tmux併用時の注意点はClaude CodeのTUI(フルスクリーン)とはにあります。エラー全般の切り分けはClaude Codeでよくあるエラー10選でも扱っています。