Codexがファイルを編集できないときは、いきなりOSのアクセス権を変更せず、次の順番で確認します。
- Codexが目的のworkspace（作業対象として開いているフォルダ）を見ているか
- sandbox modeが
read-onlyになっていないか - workspace外の操作に承認が必要なだけではないか
- 通常のターミナルからも書き込めないOS権限の問題か
この4つは別の原因です。区別せずにchmod -R 777やフルアクセスで直そうとすると、本来必要のない範囲まで書き込み可能にしてしまいます。
症状から確認先を絞る
最初に、表示されたエラーと発生範囲を照合します。
| 症状 | 可能性が高い原因 | 最初の確認 |
|---|---|---|
| Codexが「read-only」と表示する | sandbox mode | /permissionsで現在のモードを確認 |
| workspace外なので編集できない、承認を求められる | 対象パスがworkspace外 | /statusと対象ファイルの絶対パスを照合 |
| Codexでは失敗するが、通常端末では同じ場所へ書ける | Codexのsandboxまたは保護対象パス | sandbox mode、writable root、.gitなどの保護対象を確認 |
Codexでも通常端末でもPermission deniedになる |
OSの所有者・ACL・マウント状態 | Linux/WSLはls -ld、WindowsはGet-Aclを確認 |
bwrapやuser namespaceの警告後、コマンドが始まらない |
Linux/WSLのsandbox起動 | bubblewrapとAppArmorの要件を確認 |
| Windowsでsandbox setupやエラー1385が出る | Windows sandboxの初期化・ポリシー | elevated/unelevatedの状態とsandboxログを確認 |
ファイル名だけで判断せず、「通常端末でも失敗するか」を比較すると、Codex側とOS側を早く分けられます。
workspace・sandbox・approval・OS権限は別物
Agent approvals & securityでは、sandboxとapproval policy（どの操作で利用者の承認を求めるか）を別の制御として説明しています。さらに、OS自体のファイル権限はCodexの設定とは別に存在します。
| 層 | 決めること | 典型的な失敗 | 主な確認先 |
|---|---|---|---|
| workspace | 今回の作業対象に含まれるフォルダ | 別cloneや親フォルダ外を編集しようとする | /status、pwd、Git root |
| sandbox mode | Codexのコマンドが技術的に書ける範囲 | read-only、workspace外への書き込み拒否 |
/permissions、config.toml |
| approval policy | 範囲外操作を自動実行するか、人に確認するか | 承認待ち、承認却下 | 実行時の承認画面、approval_policy |
| OS権限 | 実行ユーザーがファイルへ書けるか | Permission denied、Access denied |
所有者、mode、ACL、マウント状態 |
workspace-writeは「PC内のどこでも編集できる」という意味ではありません。公式のworkspace-write定義では、cwd（現在の作業ディレクトリ）と追加のwritable rootsが書き込み範囲です。範囲外の編集には承認が必要です。
1. Codexが見ているworkspaceを確認する
Codexへ次の確認を依頼するか、Codexと同じ環境の統合ターミナルで実行します。Windows上のPowerShellとWSLのシェルでは見えるパスが異なるため、別環境の結果を比較しないでください。
pwd
git rev-parse --show-toplevel
git status --short --branch見るべき点は3つです。
pwdが意図したプロジェクト内か- Git rootがエディタで開いているリポジトリと同じか
- branchが編集したいbranchか
Codex CLIでは/statusも使えます。Agent approvals & securityによると、/statusでworkspaceに含まれるディレクトリを確認できます。対象ファイルの絶対パスがworkspace外なら、OS権限を変更してもCodex側の境界は変わりません。
WindowsとWSLを併用している場合は、似た名前の別フォルダにも注意してください。たとえばD:\dev\sampleと/home/user/dev/sampleは、同じ名前でも別の実体です。/mnt/d/dev/sampleはWindowsのDドライブをWSLから見たパスですが、/home/user/dev/sampleはWSL内のLinuxファイルシステムです。
Codexの状態保存先とプロジェクトworkspaceも別物です。CODEX_HOMEを移す話はCodexの保存場所をCドライブからDドライブへ変更する方法で扱っていますが、CODEX_HOMEを変えてもプロジェクトの書き込み範囲は増えません。
2. sandbox modeとapproval policyを確認する
Codex CLIまたはIDE extensionでは、/permissionsで現在の権限モードを確認します。公式資料では、バージョン管理されたフォルダに対してはworkspace-writeとon-request approvalを組み合わせたAutoが案内されています。計画やレビューだけを行うread-onlyでは、ファイル編集は許可されません。
| 設定 | できること | 向く用途 | 注意点 |
|---|---|---|---|
read-only |
読み取り中心 | 調査、レビュー、計画 | 編集には承認またはモード変更が必要 |
workspace-write |
workspace内を編集 | 通常の開発作業 | workspace外や保護対象は自由に編集できない |
danger-full-access |
sandboxによる制限なし | 強い隔離が別途ある特殊環境 | 通常のトラブル解決には範囲が広すぎる |
CLIを起動し直す場合は、次の指定で通常の編集範囲と承認境界を明示できます。
codex --sandbox workspace-write --ask-for-approval on-request継続して設定する場合、ユーザー設定は~/.codex/config.tomlへ記載します。Configuration Referenceでは、信頼したプロジェクトに限り.codex/config.tomlのプロジェクト設定も読み込むと説明されています。
approval_policy = "on-request"
sandbox_mode = "workspace-write"workspace外に、作業上どうしても必要なフォルダがある場合だけ、追加のwritable rootを狭い絶対パスで指定します。
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
writable_roots = ["/home/user/shared/generated-docs"]この設定はLinux/WSLの例です。ホーム全体やドライブ全体を追加するのではなく、実際に生成物を置くディレクトリまで絞ります。
workspace内でも書けない保護対象がある
workspace-writeでも、writable root内のすべてが同じ扱いになるわけではありません。Agent approvals & securityでは、.git、.agents、.codexとその配下を保護対象としてread-onlyにすると説明しています。
通常の記事やソースコードは編集できるのに、これらのディレクトリだけ失敗する場合、OS権限の不足とは限りません。Codexに保護対象を書き換えさせる必要性を確認し、必要なら操作内容を限定して承認します。
3. 通常端末からOS権限を確認する
workspaceとsandboxに問題がなければ、同じユーザーで開いた通常端末から書き込み可否を確認します。ここで通常端末でも失敗するなら、Codexの設定よりOS側を調べます。
Linux・WSL
対象ファイルをsrc/example.txtとした確認例です。
id
ls -ld . src src/example.txt
namei -l src/example.txt
test -w src/example.txt && echo writable || echo not-writableファイルだけでなく、親ディレクトリにも注目します。新規ファイルの作成や既存ファイルの置換には、親ディレクトリへの書き込み権限が必要です。所有者が別ユーザーになっている場合は、なぜそうなったかを確認してから、そのファイルまたは必要なディレクトリだけを修正します。
nameiがインストールされていない環境では、その行を省略しても構いません。ls -ldで対象と親ディレクトリを個別に確認できます。
WSLで/mnt/cや/mnt/d配下を使う場合、Linuxのmode表示だけでなくWindows側のACL（アクセス制御リスト）やマウント設定も影響します。WSLホームでは成功し、マウントしたドライブだけ失敗するなら、Windows側の権限も確認対象です。
Windows PowerShell
Get-Location
Get-Acl -LiteralPath "D:\dev\sample\src\example.txt" | Format-List
Get-Acl -LiteralPath "D:\dev\sample\src" | Format-ListACLでは、現在のWindowsユーザーに書き込みが許可されているか、明示的な拒否がないかを確認します。会社管理PCではポリシーが設定されている場合があるため、所有権やACLをまとめて変更せず、管理者へ対象パスとエラーを共有します。
最小の書き込みテスト
既存ファイルを壊さないよう、プロジェクト内の専用一時ファイルで試します。
Linux・WSL:
touch ./codex-write-test.tmp
ls -l ./codex-write-test.tmp
rm ./codex-write-test.tmpWindows PowerShell:
$testPath = Join-Path (Get-Location) "codex-write-test.tmp"
New-Item -ItemType File -Path $testPath -ErrorAction Stop
Get-Item -LiteralPath $testPath
Remove-Item -LiteralPath $testPath通常端末では成功するのにCodexから同じテストが失敗する場合、OS権限を広げず、workspaceとsandboxの確認へ戻ります。
4. コマンド自体が始まらない場合はsandbox実装を確認する
ファイル操作の途中でPermission deniedになるケースと、sandboxの準備段階でコマンドが起動しないケースは分けて考えます。
Linux・WSLではbubblewrapを確認する
Sandboxingによると、LinuxとWSL2のCodexはbubblewrapを使います。公式資料は、ディストリビューションのパッケージ管理でbubblewrapをインストールする方法を案内しています。
Ubuntu・Debianの場合:
sudo apt install bubblewrap
which bwrap
bwrap --versionbwrapがない、またはunprivileged user namespaceを作成できないという起動警告が出る場合、対象記事ファイルへchmodしても直りません。Ubuntu 24.04などAppArmorの制限が関係する環境については、公式のSandboxingにディストリビューション別の手順があります。カーネルの保護設定を全体で無効化する前に、配布パッケージと専用AppArmor profileで解決できるか確認します。
Windowsネイティブではsandbox modeを確認する
Windows sandboxでは、Windowsネイティブ実行にelevatedとunelevatedの2方式があり、elevatedを推奨、利用できない環境ではunelevatedをfallbackとしています。
[windows]
sandbox = "elevated" # または "unelevated"elevatedの初期化には管理者承認やローカルポリシーが関係します。会社管理PCでsetupが失敗する、またはWindowsエラー1385が出る場合は、ACLを手当たり次第に変えず、IT管理者へ相談します。一時的にunelevatedで動作を切り分けられますが、公式資料では隔離が弱いfallbackとして位置付けられています。
Windows固有のsandboxログはCODEX_HOME/.sandbox/sandbox.logです。OpenAIや管理者へ診断情報を渡す場合も、CODEX_HOME/.sandbox-secrets/の内容は共有しません。
安全に直すための判断表
原因を特定したら、変更範囲を最小にします。
| 確認結果 | 対応 | トレードオフ |
|---|---|---|
| 間違ったworkspaceを開いていた | 正しいリポジトリを開き直す | 既存チャットの対象パスを再確認する必要がある |
read-onlyだった |
信頼できるリポジトリでworkspace-writeへ変更 |
workspace内の自動編集を許可する |
| 対象だけworkspace外だった | 操作ごとに承認するか、狭いwritable rootを追加 | 恒久設定は今後のセッションにも影響する |
| 通常端末でも書けなかった | 対象ファイル・親ディレクトリの所有者やACLを修正 | 共同開発や企業ポリシーとの整合が必要 |
| sandboxの起動が失敗した | OS別のsandbox要件を修正 | パッケージ導入や管理者・IT部門の対応が必要な場合がある |
修正後は、専用一時ファイルの作成と削除、目的ファイル1件の小さな編集、git diffの順に確認します。最初から大量ファイルの変更を再実行しない方が、原因と結果を追いやすくなります。
やってはいけない対処
chmod -R 777をプロジェクト全体へ実行する
全ユーザーへ読み書き実行を許可するため、問題の原因を隠したまま攻撃面を広げます。必要な所有者、グループ、対象パスを特定してから修正します。
Codexを常に管理者・rootで起動する
通常ユーザーで防げる誤操作まで実行可能になります。sandboxの起動要件を整え、必要なシステム操作だけ人が明示的に実行する方が安全です。
danger-full-accessを通常設定にする
workspaceの選択ミスを防げなくなります。フルアクセスが必要に見えても、追加writable rootや操作単位の承認で範囲を限定できないか先に検討します。
エラーを見ずに所有権やACLを一括変更する
会社管理PC、共有リポジトリ、WindowsとWSLをまたぐフォルダでは、別の利用者やツールを壊す可能性があります。エラー全文、対象パス、実行環境、通常端末での結果をそろえてから変更します。
直らない場合に残す情報
再現条件を次の形で残すと、Codex側・OS側・プロジェクト側のどこを調べるか判断しやすくなります。
- Codexの利用形態: デスクトップアプリ、CLI、IDE extension
- OS: Windowsネイティブ、WSL2のディストリビューション、Linux
- Codexのバージョン
/statusで確認したworkspace- sandbox modeとapproval policy
- 対象ファイルの絶対パス
- エラー全文。ただし秘密情報や認証情報は削除する
- 通常端末で同じ場所へ書き込めるか
- Linux/WSLなら
which bwrapとbwrap --version - Windowsならelevated/unelevatedの別とsandboxログの該当箇所
Codexがファイルを編集できないときは、workspace、sandbox、approval、OS権限の順に失敗した層を絞ります。修正後は小さな一時ファイルから再テストすれば、必要のない権限まで広げずに作業を再開できます。
出典
- Sandboxing — OpenAI
- Agent approvals & security — OpenAI
- Configuration Reference — OpenAI
- Windows sandbox — OpenAI
- workspace_write.md — OpenAI Codex GitHub repository
- openai/codex LICENSE — Apache License 2.0
コメント