Sandbox settings not changedの原因と直し方 — Claude Code /sandbox
/sandboxで選んだモードが保存できないとき、括弧内のEACCES・EPERM・EROFS・Invalid JSON syntaxで直し方が分かれます。書き込める場所がない場合の~/.claude/settings.json設定も。
/sandboxで次の行が出たら、パネルで選んだモードがプロジェクトの.claude/settings.local.jsonに保存できていません。サンドボックスの設定は変わっていない状態です。
✗ Sandbox settings not changed: /home/you/project/.claude/settings.local.json couldn't be updated (EACCES). Start Claude Code in a project folder you can write to.直し方は、行末の括弧の中身で決まります。EACCES・EPERM・EROFSなら書き込める場所の問題、Invalid JSON syntax in settings fileで始まるならJSONの壊れです。書き込める場所がどこにもないときは、ユーザー設定に書く逃げ道があります。
まず括弧の中の理由を読む
メッセージは「どのファイルに」「なぜ失敗したか」を含んでいます。パスの部分が、保存に失敗した.claude/settings.local.jsonです。理由は2系統に分かれます。
| 括弧内の理由 | 意味 | 直し方 |
|---|---|---|
EACCES / EPERM / EROFS | 意味そのプロジェクトの.claude/settings.local.jsonに書き込めない | 直し方書き込めるプロジェクトフォルダでClaude Codeを起動し直し、/sandboxをやり直す |
Invalid JSON syntax in settings fileで始まる | 意味ファイルがあるがJSONとして読めない | 直し方.claude/settings.local.jsonのJSONを直し、/sandboxをやり直す |
どちらの直し方も取れないときは、~/.claude/settings.jsonにsandbox.enabledを書く方法があります。どの理由でも、直したあとは同じセッションで/sandboxを開き直せば足ります。
なぜ.claude/settings.local.jsonが書き込み先になるのか
/sandboxのパネルでモードを選ぶと、Claude Codeは選択を現在のプロジェクトの.claude/settings.local.jsonに保存します。このファイルは、設定の優先順位ではプロジェクトローカル設定にあたります。個人用の設定で、チームで共有する.claude/settings.jsonとは別です。保存するときにClaude Codeがグローバルのgitignoreへ追加するため、通常はコミットに混ざりません。
つまり、/sandboxは「そのプロジェクトのフォルダに書けること」を前提に動いています。ここが前提どおりでないと、冒頭の行が出ます。設定ファイルの置き場所と読み込まれ方は、Claude Codeの設定が反映されない原因でも扱っています。
同じキーが複数の場所にあるときは、高いレベルの値が使われます。優先順位は次のとおりで、上ほど強い設定です。
- 管理設定(組織が配る
managed-settings.json、MDM、claude.aiのコンソール) - コマンドライン(
--settingsで渡したJSON) - プロジェクトローカル設定(
.claude/settings.local.json) - 共有プロジェクト設定(
.claude/settings.json) - ユーザー設定(
~/.claude/settings.json)
/sandboxの保存先は3番目です。保存に失敗する原因は、この3番目のファイルに書けないことに限られます。1番目か2番目がsandbox.enabledなどを握っている場合は、保存の失敗ではなく、パネルが開かない別のエラーになります。
書き込み系の理由(EACCES / EPERM / EROFS)の直し方
3つのコードはいずれもOSが返す書き込み失敗の理由です。EACCESとEPERMは権限、EROFSは読み取り専用のファイルシステムを指します。いずれの場合も打つ手は同じで、書き込めるプロジェクトフォルダでClaude Codeを起動し直します。
起動した場所のフォルダに書けるかは、シェルで先に確かめられます。
ls -ld .claude
touch .claude/.write-test && rm .claude/.write-test2行目が失敗するなら、そのフォルダでは/sandboxの保存も通りません。所有者が違うフォルダ、読み取り専用でマウントされたフォルダ、権限を絞った共有ディレクトリなどが典型です。自分のホーム配下にプロジェクトをコピーするか、書き込める別のフォルダでClaude Codeを起動します。
保存に失敗したときの切り分け
- Q括弧の中は EACCES・EPERM・EROFS のどれか?答えがいいえ(Invalid JSON syntax)答えがはい
.claude/settings.local.jsonを開き、JSONの構文エラーを直します。直したら/sandboxをやり直します。 - Q書き込めるプロジェクトフォルダで起動できるか?答えがいいえのとき答えがはい
~/.claude/settings.jsonにsandbox.enabledを書きます。次の節の手順です。
書き込めるフォルダで起動し直す
同じセッションで/sandboxを実行し直します。
JSONの壊れ(Invalid JSON syntax in settings file)の直し方
理由がInvalid JSON syntax in settings fileで始まる場合、.claude/settings.local.jsonは存在していますが、JSONとして解釈できません。JSONとして読めないファイルには、選んだモードを保存できません。
よくある壊れ方は、末尾のカンマ、閉じ忘れの波括弧、手で足したコメントです。構文は次のコマンドで確かめられます。
python3 -m json.tool .claude/settings.local.jsonエラーの行番号が出たら、その付近を直します。中身が不要なら、バックアップを取ってから最小の有効なJSON{}にしても構いません。そのファイルに入っていた個人用の許可ルールなどは失われるため、消す前に控えを残しておくと安全です。直したあとに/sandboxをやり直します。
設定ファイルを直すときの注意
壊れたJSONは、Claude Codeを起動した直後にも検出されます。ユーザー・プロジェクト・ローカルのいずれかのファイルが不正なJSONだと、対話セッションの開始時に「Settings Error」のダイアログが出て、Claudeの助けを借りて直す、終了する、壊れた設定なしで続ける、のどれかを選べます。ダイアログで「壊れた設定なしで続ける」を選ぶと、そのファイルの値は使われないまま作業が進みます。/statusのSetting sources行で読み込まれたファイルを、claude doctorで拒否された項目を確認できます。
もう一点、Claudeに実行させたシェルコマンドでこのファイルを直そうとしても、うまくいかないことがあります。サンドボックスは、書き込みを許した範囲の中でも、.claudeの設定ファイルへの書き込みを拒否するためです。保護の対象には.mcp.jsonや.bashrc、.gitconfigなども含まれます。allowWriteで許可しても保護は外れません。直すときは、エディターで開くか、サンドボックスの外で動く!プロンプトから操作します。
書き込める場所が無いとき: ユーザー設定で有効にする
プロジェクトフォルダに書けない環境でも、ユーザー設定は別の場所にあります。~/.claude/settings.jsonに次を追加します。
{
"sandbox": {
"enabled": true
}
}この設定はauto-allowモードをオンにします。auto-allowでは、サンドボックス内で動くコマンドが確認なしで承認されます。通常の許可確認を残す「regular permissions」モードにしたい場合は、sandbox.autoAllowBashIfSandboxedもfalseにします。
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": false
}
}変更は、実行中のセッションでも次にClaude Codeが実行するシェルコマンドから反映されます。/sandboxのModeタブには、有効なモードが印として表示されます。再起動は要りません。
2つのモードの違いは、サンドボックス内のコマンドを確認なしで通すかどうかだけです。ファイルとネットワークの制限は、どちらでも同じです。
- auto-allow(
sandbox.enabled: trueのみ): サンドボックス内で動くコマンドは、確認なしで承認されます。excludedCommandsに一致するコマンドや、サンドボックス外での再実行は、通常の許可の流れに戻ります。Bash(git push *)のような内容つきのaskルールは、サンドボックス内でも確認を出します。 - regular permissions(
autoAllowBashIfSandboxed: falseを追加): すべてのBashコマンドが通常の許可の流れを通ります。確認の回数は増えますが、操作を細かく見たいときに向きます。
~/.claude/settings.jsonに書いた値は、そのユーザーの全プロジェクトに効きます。プロジェクトごとに切り替えたい場合は、書き込めるプロジェクトでの/sandboxのほうが範囲を絞れます。sandbox.enabledそのものの挙動はsandbox.enabledの解説にまとめています。
ファイルに何も書かず、1回のセッションだけサンドボックスを有効にする方法もあります。--settingsにJSONを渡して起動します。
claude --settings '{"sandbox": {"enabled": true}}'--settingsはコマンドラインのレベルなので、プロジェクトのファイルより強く効きます。そのセッションでは/sandboxが「Sandbox settings are overridden…」のエラーになる場合があるため、あとからモードを切り替えたいときは付けずに起動します。
似た症状との見分け方
/sandboxの失敗には、似た見た目で原因の違う症状があります。
Error: Sandbox settings are overridden by a higher-priority configuration and cannot be changed locally.: 保存の失敗ではなく、パネルが開かないエラーです。--settingsや管理設定がsandbox.enabledなどを握っているときに出ます。/statusのSetting sources行で、Command line argumentsかEnterprise managed settingsが載っているかを見ます。管理設定が原因なら、手元のファイルでは変えられません。- 「Yes, and don't ask again」を選んでも保存されない: LinuxやWSL2で、
.claude配下の設定パスに0バイトの読み取り専用ファイルが残っているのが原因になりえます。claude doctorで一覧できます。扱いはstale sandbox mask files警告の手順にあります。仕組みは次のとおりです。サンドボックスは、まだ存在しない書き込み禁止の対象に、実行中だけ0バイトの読み取り専用ファイルを置きます。セッションがSIGKILLなどで強制終了されたり、バックグラウンドのコマンドが動いたまま終了したりすると、後始末が走らずに残ります。残ったファイルは次のセッションからも読み取り専用で束ねられ続けます。削除は、そのプロジェクトで他のClaude Codeセッションが動いていないときにrmで行います。 - コンテナの中で
Operation not permittedが出てサンドボックス内のコマンドが動かない: 設定の保存とは別の問題で、権限のないコンテナでは/procをマウントできないことが原因です。sandbox.enableWeakerNestedSandboxをtrueにする手がありますが、外側のコンテナが必要な分離をすでに提供している場合に限ります。
本記事の行は、Sandbox settings not changed:で始まり、括弧に理由が付く点で見分けられます。
直ったかの確かめ方
/sandboxを開き直し、Modeタブで選んだモードが有効になっていれば保存は通っています。ファイルに書かれたかは、.claude/settings.local.jsonのsandboxキーで確かめられます。
サンドボックスそのものが効いているかは、別の確認です。Claude Codeにtouch ~/sandbox-probeを実行させると、サンドボックス内ではmacOSでOperation not permitted、LinuxとWSL2でRead-only file systemになります。自分で!プロンプトに打った行は通常サンドボックスの外で動くため、この確認には使えません。
まとめ
行末の括弧が分かれ道です。書き込み失敗の3コードなら起動する場所を変え、Invalid JSON syntaxならファイルのJSONを直します。どちらも取れないときは、~/.claude/settings.jsonにsandbox.enabledを置けば、/sandboxを通さずに同じ状態にできます。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。