「Cannot switch renderers in this session」の意味と対処法
/tuiでフルスクリーン表示に切り替えられない「Cannot switch renderers in this session」の原因4つと、バックグラウンド版のメッセージとの違いを見分けます。
/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は再起動そのものを拒否し、設定も変更せずに終了します。この記事が扱うのは「in this session」の文言が付く版です。もう一つ別のバージョンもあり、原因も対処もまったく異なります。バックグラウンド処理が実行中のときに出る「Cannot switch renderers while work is running in the background」です。
v2.1.234より前のバージョンでは、この確認自体が存在しませんでした。制約があっても構わず再起動し、再起動後のセッションはその制約なしで動いていました。つまり以前は「起動時に指定したツール許可リストやシステムプロンプトの上書きが、/tuiを経由すると静かに外れる」という状態でした。現在のバージョンはこれを止め、代わりに理由を明示して切り替えを拒否します。
メッセージの括弧内が示す4つの原因
エラーメッセージの括弧内には、該当した制約の種類がそのまま書かれます。
| 括弧内の文言 | 原因 |
|---|---|
launch flags: a custom system prompt, a tool allowlist, or restricted settings | 原因--system-prompt・--system-prompt-file・--append-system-prompt-file・--tools・--setting-sources・--permission-prompt-toolのいずれかを指定して起動している |
permission rules set for this session only | 原因フックやSDKからの権限更新で、sessionスコープのdeny/askルールが追加されている(sessionスコープのallowルールはこの拒否の引き金にはなりません) |
ask-before-running rules with no command-line form | 原因フックやSDKが追加したaskルールに、コマンドライン引数として渡せる形が存在しない |
permission rules a command line cannot carry intact / added directories a command line cannot carry intact | 原因セッション途中で追加された権限ルールやディレクトリが、コマンドライン引数の値として渡せない |
共通しているのは、いずれも「起動時のコマンドラインに戻せない設定」だという点です。/tuiは新しいプロセスを起動し直す仕組みのため、セッション限定で動的に追加されたルールや、コマンドライン引数として表現できない制約は再現できません。
なぜエラーにしてまで再起動を拒否するのか
v2.1.234より前の挙動を踏まえると、この拒否は単なる利便性の制限ではなく、意図しない権限の緩和を防ぐための変更だと分かります。フックやSDK呼び出し元がセッション限定で追加したdeny/askルールは、実行中のプロセスのメモリ上にしか存在しません。以前のバージョンのように制約を無視して再起動していた場合、新しいプロセスは設定ファイルを読み直すだけです。メモリ上にしかなかったセッション限定のルールは引き継がれず、そのルールが無かったことになった状態で会話が続いていました。ユーザーから見れば表示モードを変えただけのつもりが、結果的に権限のガードが一枚外れる、という副作用です。
現在のバージョンがエラーで止めるのは、この副作用を「静かに起きる」状態から「明示的に拒否して知らせる」状態に変えるための設計です。同じ理由で、--system-promptや--toolsのような起動フラグも、再起動後のコマンドラインに正確な形で戻せない場合は同様に拒否されます。制約が外れたまま作業を続けるより、フルスクリーン表示を諦めて通常レンダラーのまま作業を続けるほうが、権限管理の観点では安全な選択です。
すぐに実行する対処
Cannot switch renderersが出た場合、そのセッション内でできることはありません。制約を持たない新しいセッションを別途起動し、そちらで/tui fullscreenを実行します。
/tui fullscreen一度tui設定を保存すれば、以降のセッションはすべてその設定を引き継ぎます。制約付きのセッションだけが対象外になる、という理解で問題ありません。フルスクリーン表示のちらつき軽減だけを先に体験したい場合は、/tuiを経由せず起動時から有効にする方法もあります。
CLAUDE_CODE_NO_FLICKER=1 claudeCLAUDE_CODE_NO_FLICKERとtui設定は等価に扱われるため、この環境変数を付けて起動すれば/tuiによる再起動を経由せずに済みます。ただし--system-promptのようなフラグ自体を外さない限り、そのセッションが抱える制約は変わりません。制約付きのまま通常レンダラーで作業を続けても機能面での不利益はなく、あくまで表示のちらつき軽減とマウス操作を諦めるだけです。
CI・自動化・ラッパースクリプトで踏みやすい理由
--system-promptや--toolsによるツール許可リストの指定は、CI・自動化パイプライン・社内ラッパースクリプト経由の起動で特に多く使われます。こうした起動方法を日常的に使っているチームほど、/tuiによるレンダラー切り替えを想定しないほうが安全です。フルスクリーン表示のちらつき軽減を業務で使いたい場合は、/tuiでの事後切り替えを諦め、起動コマンド自体にCLAUDE_CODE_NO_FLICKER=1を含める形に変えます。これなら制約付きセッションでも最初からフルスクリーン表示を有効にできます。
立場別の恒久対応
原因を特定したら、次に「今後もこの制約付きで運用し続けるか」を判断します。恒久的にフルスクリーン表示を使いたい場合の対応は、原因を作っている側によって変わります。
| 立場 | 恒久対応 |
|---|---|
--system-prompt/--toolsを自分で指定して起動している | 恒久対応起動コマンドにCLAUDE_CODE_NO_FLICKER=1を含め、/tuiを経由せず最初からフルスクリーンで起動する |
| チーム共有のフック設定がセッション限定の権限ルールを追加している | 恒久対応フック設定の変更はチーム全体に影響するため、フック作成者と調整してから変更する。個人の判断だけで外さない |
| Agent SDK経由でセッション限定ルールを付与している | 恒久対応SDK呼び出しコード側で権限更新のスコープを見直すか、そのセッションではフルスクリーン表示を諦める |
| CI・自動化パイプラインからの起動 | 恒久対応対話的な表示モードの恩恵自体が小さいため、無理に切り替えず通常レンダラーのまま運用する |
チーム共有のフックやSDK側の設定を自分の判断だけで緩めると、そのセッション限定のガードを別の場面でも失うリスクがあります。個人の作業効率のためにセキュリティ上の制約を外すべきかどうかは、設定した本人や管理者と相談してから決めます。表示の快適さと権限管理の厳密さは、多くの現場でトレードオフの関係にあります。
バックグラウンド処理中の別バージョンとの違い
原因も対処もまったく異なるもう一つのメッセージが「Cannot switch renderers while work is running in the background」です。こちらはセッション自体に制約があるのではなく、バックグラウンドのBashコマンドやサブエージェントが実行中で、プロセスの再起動がその処理を巻き添えにしてしまうために出ます。
| メッセージ | 原因 | 対処 |
|---|---|---|
in this session | 原因セッションに再起動先へ引き継げない制約がある | 対処制約のない新しいセッションで切り替える |
while work is running in the background | 原因バックグラウンド処理が実行中 | 対処/tasksで処理を確認し、完了か停止を待ってから再実行する |
while work is runningのほうは一時的な状態であり、バックグラウンド処理が終わってから同じ/tui fullscreenを実行すれば、多くの場合はそのまま切り替えられます。in this sessionのほうは、そのセッションが存在する限り解消しない恒久的な制約です。両方が同時に起きているように見えても、実際にはどちらか一方の理由でしか拒否されません。表示されたメッセージの文言をそのまま読めば、どちらに該当しているかを取り違えることはありません。
よくある質問
制約を解除して同じセッションのまま切り替える方法はありますか
ありません。--system-promptや--toolsは起動時にしか指定できないフラグで、セッション途中で取り消す手段は用意されていません。フルスクリーン表示を使いたいなら、それらのフラグを付けずに新しいセッションを起動する必要があります。
スクリーンリーダーモードでも同じメッセージが出ますか
出ません。スクリーンリーダーモードでは、アタッチしたバックグラウンドセッションを除いて常に通常レンダラーが使われます。/tui fullscreenを実行すると別の説明メッセージが表示され、tui設定自体は変更されません。今回のエラーとは別の制御です。
エラーが出てもtui設定は保存されますか
保存されません。メッセージの通り「Nothing was changed」で、切り替えの試行自体が失敗として扱われ、既存の設定はそのまま残ります。何度実行しても状態が壊れることはありません。
フックが追加した権限ルールかどうかはどう確認しますか
括弧内の文言で分かります。次のいずれかがあれば、フックまたはSDK呼び出し元がそのセッション限定で追加したルールが原因です。
permission rules set for this session onlyask-before-running rules with no command-line form
心当たりがなければ、起動に使っているフック設定やSDK呼び出しコードを確認します。
制約付きのセッションだと分かるのはエラーが出たときだけですか
事前に確認する専用コマンドは公式には案内されていません。起動時に--system-promptや--toolsを自分で指定していれば分かります。一方でフックやSDKが動的に追加したセッション限定のルールは、/tuiを実際に試してエラーが出るまで気付きにくいのが実情です。
/tui以外のコマンドでも同じ制約は関係しますか
/tuiはプロセスを再起動する数少ないコマンドの一つで、この種の拒否が起きるのも主に/tui経由の切り替えです。/clearや/compactのようにプロセスを再起動しない他のコマンドは、今回の制約とは無関係にそのまま実行できます。
Desktop版やVS Code拡張でも同じエラーが出ますか
出ません。/tuiとフルスクリーンレンダリングは、ターミナルの代替スクリーンバッファを使うCLI固有の仕組みです。Desktop版やIDE拡張はそもそもターミナルの画面描画モデルに依存しないため、この切り替えという概念自体が存在しません。
まとめ
「Cannot switch renderers in this session」は、そのセッションに再起動先へ引き継げない制約が掛かっているときに出ます。原因は起動フラグとセッション限定の権限ルールに大別できます。括弧内の文言で該当する原因を特定でき、対処は制約のない新しいセッションで切り替えるか、起動時からCLAUDE_CODE_NO_FLICKER=1を使う二択です。バックグラウンド処理中に出る別バージョンのメッセージとは原因も対処も異なるため、文言の違いを見落とさないようにします。フルスクリーン表示の仕組みそのものや、マウス操作・tmux併用時の注意点はClaude CodeのTUI(フルスクリーン)とはにまとめています。一般的なエラーの切り分け方はClaude Codeでよくあるエラー10選も参考になります。