Codexのsandboxエラーを解決する|書き込み範囲と権限不足の切り分け

Codexでファイルの書き込みやコマンド実行が拒否されたときに、sandboxの境界、作業ディレクトリ、書き込み先、承認の要否を順番に切り分ける方法を解説します。

Codexで「権限がない」「sandboxの外へ書き込めない」と表示されても、すぐに制限を解除する必要はありません。拒否対象、作業ディレクトリ、書き込み範囲を順に確認すれば、安全な設定のまま進められる場合があります。別の停止原因も調べたい場合は、Codexが途中で止まるときの原因と対処法も参照してください。

sandboxが守っている範囲

sandbox(サンドボックス)は、Codexがコマンドを実行するときの技術的な境界です。公式資料では、書き込める場所、ネットワーク接続、保護パスをsandboxが決め、承認ポリシーは確認を求めるタイミングを決めると説明されています。

主なモードはread-onlyworkspace-writedanger-full-accessの3種類です。前者は読み取り、中央は作業場所を中心とした書き込み向けです。danger-full-accessは範囲が大きいため、単にエラーを消す目的では選びません。

モード主な用途書き込みネットワークエラー時の見方
read-only調査・レビュー原則不可制限あり書き込みを伴う依頼ならモードと目的が不一致
workspace-write通常の開発作業workspaceと追加許可した場所既定では無効出力先が境界内か、保護パスでないかを確認
danger-full-access隔離済み環境などでの限定用途sandboxによる制限なしsandboxによる制限なしエラー解消だけを理由に切り替えない

workspace-writeでも、保護パス、OSのアクセス制御、組織の管理設定により編集できない場所があります。ネットワーク接続も別設定なので、パッケージ取得の失敗をファイル権限の問題と決めつけないでください。

エラー文から拒否対象を特定する

最初に見るのは、長いエラー全文のうち次の4点です。

  1. 失敗した操作は読み取り、作成、変更、削除、コマンド実行のどれか
  2. 拒否されたファイルまたはディレクトリの絶対パス
  3. permission deniedaccess deniedread-onlyなどの理由
  4. コマンドが起動前に拒否されたか、起動後に終了コードを返したか

作業場所がD:\work\sampleで出力先がD:\exports\result.jsonなら、workspace外への書き込みを疑います。対象がworkspace内なら、読み取り専用属性、別プロセスによる使用、OS側のアクセス権、保護された子ディレクトリを調べます。

Windows向けの公式解説では、作業ディレクトリや追加したwritable_rootsに書き込みを許可する一方、.git.codex.agentsなどは「書き込み可能な範囲内の読み取り専用パス」として扱う設計例が示されています。workspace内というだけで、すべての子パスへ書けるとは限りません。

エラーを共有するときはAPIキーや個人情報を伏せつつ、「現在地」「拒否された相対位置」「実行した操作」は残します。

作業ディレクトリを確認する

次に、Codexがどのフォルダを作業場所として認識しているか確認します。画面のセッション情報に作業ディレクトリが表示されている場合は、その値を見ます。シェルで確認するなら、環境に応じて次を使えます。

Get-Location
Resolve-Path -LiteralPath .
pwd

表示場所がリポジトリのルートと一致するか確認します。別の階層から開始した場合は、正しいプロジェクトを作業ディレクトリにしてセッションを開始し直す方が、権限を広げるより安全です。

相対パスは現在地が基準です。../outputは親フォルダを指します。対象の明記方法はCodexへの依頼テンプレートで確認できます。まず読み取りだけ行い、絶対パスが予想どおりか確かめます。

書き込み先を安全に絞る

作業ディレクトリが正しいなら、まず成果物をworkspace内のoutputなどへ作り、確認後に必要な場所へ移します。

どうしても別の開発ディレクトリへ書き込む必要がある場合、公式設定にはworkspace-writeで追加の書き込み先を指定するwritable_rootsがあります。設定例は次の形ですが、実際のパスは自分が所有し、作業に必要な最小のフォルダだけにします。

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["D:\\work\\shared-output"]
network_access = false

設定の置き場所やApp・CLIでの反映範囲は変わり得るため、公式資料で確認します。変更後は既存ファイルを上書きせず、検証用ファイルを1つ作って試します。

追加先を広くしすぎると、別プロジェクトや個人フォルダまで変更対象になります。共通の親フォルダではなく、今回の出力に必要な最下層のフォルダを指定してください。

承認が必要な操作を分ける

エラーに見えても、実際は処理の失敗ではなく承認待ちの場合があります。画面に「許可」「承認」「このセッションで許可」などの選択が出ていないか確認します。公式設定ではapproval_policyがコマンド実行前にCodexを停止させる条件を制御します。現在の選択肢にはuntrustedon-requestneverなどがありますが、非対話実行向けのneverは、承認が必要な操作を自動的に安全へ変える設定ではありません。

承認時はコマンド名だけでなく、対象パスと副作用を読みます。依存導入、workspace外への書き込み、削除、管理者権限、外部通信は別々に判断し、必要な1操作へ限定します。

管理端末では、管理者がモードや承認ポリシーを固定している場合があります。回避せず、必要な作業、対象パス、書き込み内容を管理者へ伝えます。

設定を緩めずに進める代替策

権限追加がすぐにできない場合も、作業全体を止める必要はありません。次の順で、境界内に残る代替策を試します。

  • 外部フォルダは読み取りだけにし、修正版をworkspace内の新規ファイルとして作る
  • 変更差分や移動コマンドをCodexに作らせ、最後の適用だけを人が確認して行う
  • 一括処理を調査、生成、検証、配置に分ける
  • 既存依存だけでテストし、外部取得が必要な工程を分ける
  • 拒否された操作、絶対パス、sandboxモード、承認結果を短いログに残す

「書けないから全面許可」ではなく、安全に進められる範囲を探します。構成を整理したい場合は、Claude Codeで最初に作るフォルダ構成も参考になります。

最後に同じ小さな操作を再実行し、期待したファイルだけが作られたか確認します。パッチ適用時だけ失敗する場合は、権限以外の原因もあるため、Codexが途中で止まるときの原因と対処法も切り分けに使えます。解決しない場合は、Codexの画面、OS、バージョン、エラー全文を揃え、推測で制限を外さず公式サポート情報を確認してください。

よくある質問

workspace-writeなのにPermission deniedになるのはなぜですか

出力先がworkspace外、保護パス、OS側のアクセス権不足、別プロセスによるロックのいずれかが考えられます。まず現在地と拒否された絶対パスを照合し、workspace内なら対象の属性と使用状況を確認します。

writable_rootsを追加すれば、配下のすべてを書き換えられますか

必ずしも書き換えられません。公式資料では、追加の書き込み先を指定できる一方、.gitなど一部の保護パスは書き込み可能な範囲内でも保護されると説明されています。OSや組織の制限も別に適用されます。

approval_policy = "never"にすれば権限エラーは消えますか

消えるとは限りません。approval_policyは確認を求める条件、sandboxは技術的な実行境界を決めます。neverは非対話実行向けの選択肢であり、sandbox外の操作を許可する設定ではありません。

ネットワークエラーもsandboxの権限エラーですか

ファイル権限とは別に切り分けます。workspace-writeではネットワークアクセスを個別に設定でき、既定で無効の構成があります。失敗したURL、名前解決、プロキシ、承認表示を確認してください。

Windowsで管理者として起動すれば解決しますか

OS側の権限不足には影響する場合がありますが、sandboxの境界や保護パスまで自動的に解消するとは限りません。まずパスと拒否理由を特定し、管理者権限が本当に必要な操作だけに限定します。

一次情報の確認メモ

続き(結論と実データ)はnoteに置いています

ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。

noteで続きを読む Xをフォローする