Claude Desktop LinuxでGPUが無効になる原因と設定ファイルでの戻し方
Linux版のClaude Desktopで、クラッシュしていないのにGPU描画が切られる報告の整理です。設定ファイルの3つのフラグ、プロセス引数での確認、戻し方と注意点をまとめます。
Linux版のClaude Desktopで描画が重いとき、GPUアクセラレーション(ハードウェアアクセラレーション)が知らないうちに切られている可能性があります。GitHub Issue #102745の報告者は、アプリがクラッシュしていないのに「GPUが無効になった」と判定され、その結果が設定ファイルに保存されて、設定画面からは戻せなくなったと書いています。戻し方は、アプリを完全に終了して設定ファイルの2つのフラグを false にし、起動し直すことです。
この記事では、設定ファイルのどこを見るか、実際に無効になっているかをプロセスの引数で確かめる方法、戻したあとの注意点を順に扱います。なお、これは公式ドキュメントに載った機能ではなく、Issueの報告に基づく内容です。Issueには invalid ラベルが付いており、条件も1人分の環境に限られます。断定できる範囲と、報告者の推測にとどまる範囲を分けて書きます。
「クラッシュ報告が出ていないのにGPUが切られる」とはどういう状態か
報告されている状態は3点です。
- 設定画面にハードウェアアクセラレーションを戻す項目が見つからない
- 設定ファイルに、無効を示すフラグが書き込まれている
- アプリは一度も落ちておらず、エラー表示も見ていない
報告者の環境は、LinuxのX11セッションで、--ozone-platform=x11 を付けて起動したClaude Desktopです。Issueの本文にはGPUやドライバーの記入欄が埋まらないまま残っており、バージョンの欄も未記入です。再現手順は「Claudeを開くだけ」とあり、条件を絞り込める情報はほとんどありません。
Issueの題名は「False Claude crash report」で、誤ったクラッシュ報告によって自動無効化が働いたという見立てです。ただし、アプリ内部で何が誤検知されたのかは、Issueには書かれていません。報告者が確かめたのは、設定ファイルの値とプロセスの起動引数の2つだけです。
設定ファイルの3つのフラグで状態を読む
設定ファイルは ~/.config/Claude/claude_desktop_config.json です。Issueでは次の3行が入っていたとされています。
"isHardwareAccelerationDisabled": true,
"isHardwareAccelerationAutoDisabled": true,
"isHardwareAccelerationAutoDisableNoticePending": false3つのキーの意味は、Issueの文面から読める範囲では次のとおりです。
| キー | 報告された値 | 読み取れること |
|---|---|---|
isHardwareAccelerationDisabled | 報告された値true | 読み取れることGPU描画を使わない設定が有効 |
isHardwareAccelerationAutoDisabled | 報告された値true | 読み取れることその無効化が利用者の操作でなく自動で入った |
isHardwareAccelerationAutoDisableNoticePending | 報告された値false | 読み取れること利用者に知らせる通知は保留になっていない |
3つ目が false だった点が、報告の核心です。自動で無効にしたのに通知の保留もなく、報告者は「無効にされた」ことを一度も告げられませんでした。この3つのキー名は公式ドキュメントに記載がなく、意味の確認はできません。上の表は、Issueの記述と名前からの読み取りです。
実際にGPUが切られているかをプロセスの引数で確かめる
設定ファイルの値だけでは、描画の実態は分かりません。報告者はプロセスの引数で確かめています。
pgrep -a -i claude | grep -E "use-gl|disable-gpu"Issueでは、無効な状態のときに次の2種類の引数が見えたと報告されています。
- GPUプロセスに
--use-gl=disabled - レンダラーに
--disable-gpu-compositing
戻したあとは、GPUプロセスが通常どおり起動し、--use-gl=disabled の引数が付かなくなったとあります。何も出力されなければ、少なくとも報告と同じ形では無効化されていません。
戻し方:完全に終了してから2つのフラグを書き換える
報告者が試した回避策は、次の流れです。
設定ファイルでGPUを戻す手順
- 1
Claude Desktopを完全に終了する
ウィンドウを閉じるだけでは、プロセスが残っていることがあります。
pgrep -a -i claudeで何も出なくなるまで待ちます。 - 2
設定ファイルをバックアップする
書き換える前にコピーを取っておきます。
- 3
2つのフラグを false にする
isHardwareAccelerationDisabledとisHardwareAccelerationAutoDisabledの両方をfalseにします。 - 4
起動し直して引数を確かめる
先ほどの
pgrepで--use-gl=disabledが消えていれば、報告と同じ状態に戻っています。
手順2と3は、コマンドなら次のようになります。jq が入っている環境を前提にした一例で、Issueに載っているコマンドではありません。
cd ~/.config/Claude
cp claude_desktop_config.json claude_desktop_config.json.bak
jq '.isHardwareAccelerationDisabled = false
| .isHardwareAccelerationAutoDisabled = false' \
claude_desktop_config.json > /tmp/claude_cfg.json \
&& mv /tmp/claude_cfg.json claude_desktop_config.json設定ファイルには、MCPサーバーの定義など別の設定も入っています。手で編集するときは、JSONのカンマと引用符を壊さないよう、保存後に jq . claude_desktop_config.json で読み込めることを確かめておくと安全です。
起動直後に固まるときは、先にプロセスを止める
別のIssue #76307は、同じフラグの別の症状を扱っています。こちらは実際にGPUドライバーの不調が起き、「Graphics Error」のダイアログのあとで同じ2つのフラグが true で保存されたケースです。その後は毎回、ウィンドウが描画される前にメインプロセスがCPUを1コア分使い切り、ログも書かれなくなったと報告されています。
2つのIssueの違い
Issue #102745
アプリはクラッシュせず、エラーも見ていない。無効化されたのに通知もない。設定ファイルを直せばGPUが戻った。
Issue #76307
GPUドライバーの不調のあとに自動で保存され、起動のたびにCPUが100%になった。フラグを false にすると正常に起動した。
#76307の報告者は、フラグを true に戻すと同じ症状が決定的に再現したとも書いています。ウィンドウが出ずCPUが張り付いている場合は、まずプロセスを終了させてから設定ファイルを直します。
pkill -f -i claude
pgrep -a -i claudepkill は名前にclaudeを含む全プロセスを止めるため、ターミナルで動かしているClaude Codeのセッションも終わります。2つ目のコマンドで何も出なければ、終了できています。#76307は「Claude Codeの話ではない」としてクローズ(not planned)され、その後ロックされました。#102745にはコメントがまだ付いておらず、対応方針は示されていません。
戻したあとに残る疑問
次の点は、Issueからは分かりません。
- フラグが再び立つ条件:戻した後に、再び自動で
trueに書き換えられるかは報告がありません。報告者が求めているのは、1回のGPUプロセスのエラーで永続化せず、次回起動で再試行するか利用者に確認する挙動です。 - 原因となった誤検知の中身:題名のとおり誤検知とされていますが、何が検知条件に当たったのかは書かれていません。
- GPU自体の不具合との切り分け:#76307のように、実際にドライバー側の問題がある環境で
falseに戻すと、もとのGPUエラーが再発する可能性があります。再発したときに別の原因を疑う判断材料は、Issueにはありません。
報告者が求めているのは、設定画面にハードウェアアクセラレーションの切り替えを置くこと、1回のエラーで永続化しないこと、自動無効化を利用者に見えるようにすることの3点です。これらが実装されたかどうかは、Issueが開いている間は更新を待つことになります。
本当にGPUが壊れている場合との切り分け
フラグを戻して動くかどうかは、原因がGPU側にあるかで変わります。#102745は「GPU側の不具合がない環境」、#76307は「ドライバーの不調が先にあった環境」という違いがあります。手元の状況を、次の順で確かめられます。
GPUが切られた原因の切り分け
- Q`pgrep` の出力に `--use-gl=disabled` が出ているか?答えがいいえのとき答えがはい
出ていなければ、今回の症状ではありません。描画の重さは別の原因を探します。
- Q設定ファイルの2つのフラグは `true` か?答えがいいえのとき答えがはい
falseなら、フラグ以外の理由でGPUが切られています。起動オプションや環境変数を見直します。 - QドライバーのエラーやGraphics Errorのダイアログを見た覚えがないか?答えが見た覚えがある答えがはい
見た覚えがあるなら#76307に近い状態です。フラグを戻したあと、元のGPUエラーが再発しないかを様子見します。
覚えがなければ #102745 に近い状態
2つのフラグを false に戻して起動し直し、もう一度 pgrep で --use-gl=disabled が消えたことを確かめます。
ドライバー側に問題がある環境の報告は、Linux版のインストール手順の「betaで報告されている不具合」にあります。NVIDIA搭載のUbuntu 22.04でGPUプロセスの起動が error_code=1002 で失敗し、再試行のたびにログが書かれ続けた例です。こちらはフラグの問題ではなく、GPUプロセスそのものが起動できない症状なので、設定ファイルを書き換えても直るとは限りません。
Linux版は公式にはDebian系のbeta
公式のLinuxページは、Linux版をbetaとし、対象をUbuntu 22.04以降またはDebian 12以降、x86_64またはarm64としています。このページにはGPUやハードウェアアクセラレーションに触れた記述がありません。Fedoraなどでの扱いはClaude DesktopはFedora・Archで使えるかにまとめています。
症状が似ていても、原因が別のことがあります。起動のたびにサインインを求められるなら再ログインの原因、再起動でセッションが消えるならARM64版のセッション消失の領分です。インストールそのものから確認したいときはLinux版のインストール手順があります。
まとめ
GPUが無効になっているかは、設定ファイルの isHardwareAccelerationDisabled と、pgrep で見える --use-gl=disabled の2か所で確かめられます。戻すときは、必ずアプリを完全に終了してから2つのフラグを書き換えます。ウィンドウが出ずにCPUが張り付くなら、先にプロセスを止めるのが順序です。
ただし、根拠は1人の報告者のIssueと、クローズ済みの別Issueだけです。誤検知の原因も再発条件も分かっていないため、戻したあとに描画が改善したか、プロセス引数がどう変わったかを自分の環境で見て判断するのが現実的です。