Codex workspace-writeの権限・通信を確認して使い分ける

Codex workspace-writeとは何を許可する設定か

Codexのworkspace-writeを一言で言えば、Codexが作業中のフォルダーを読み取り、そこへファイルを作成・変更できるようにする設定です。コードの修正、テスト結果の保存、設定ファイルの更新など、リポジトリ内で完結する作業に向きます。ファイルを読めることと、どこへでも変更を保存できることは同じではありません。workspace-writeは対象を作業場所の内側へ寄せることで、依頼の範囲とファイルの範囲を合わせやすくします。

公式のモード定義では、書き込みできる場所として現在の作業場所と設定されたwritable_rootsが扱われます。それ以外のフォルダーを変える必要がある場合は、追加の許可を求める境界になります。したがって、ホーム全体や別のリポジトリを作業場所にしたつもりで依頼すると、意図したファイルと実際の書き込み先がずれることがあります。最初に対象フォルダーの絶対パスを確認し、不要な親フォルダーを作業場所にしないことが基本です。

読み取り専用・workspace-write・全面アクセスの違い

read-onlyは、既存のコードや設定を調べ、説明や差分案を得たいときの入口です。初めて見るリポジトリ、公開前の資料が多いフォルダー、変更の影響を先に知りたい場面では、まず読むだけの状態から始めると判断しやすくなります。作業結果をファイルに残す必要が出たら、その対象を確認してworkspace-writeへ切り替えます。

workspace-writeは、読み取りに加えて現在の作業場所への書き込みを許可します。全面アクセスは、作業場所の外側を含む広い範囲を対象にできる反面、誤ったパスを指定したときの影響も大きくなります。日常的な修正ではworkspace-writeを基準にし、全面アクセスを選ぶ理由がある場合だけ、対象と終了条件を人が先に決めるのが安全です。現在の設定で選べる三つのモードは、公式のConfiguration Referenceにも掲載されています。

「書ける」と「自由に実行できる」は同じではない

ファイルを書き込めるようにしても、どのコマンドでも無条件に実行できるわけではありません。sandbox_modeはファイルシステムと通信の境界を定め、approval_policyはコマンド実行前にCodexが停止して確認を求める条件を定めます。片方を広げたからといって、もう片方まで広がると考えないことが重要です。

たとえば、リポジトリ内のMarkdownを修正する作業はworkspace-writeだけで足りるかもしれません。一方、外部からパッケージを取得する、別の場所へ成果物をコピーする、OSの設定を変更する、といった作業は別の境界に触れます。要求された処理が作業場所の内側で完結するかを先に確かめれば、権限を広げる前に依頼文や対象パスを直せます。

2026年10月1日に確認したい公式の変化

Codex workspace-writeを調べるとき、設定だけを固定の知識として読むのは不十分です。Codex CLIは安定版と先行版が並行して公開され、同じ設定名でも説明や既定値の確認場所が更新される可能性があります。2026年10月1日に公式のリリース一覧を確認すると、安定版0.159.3のほか、0.161.0-alpha.8を含む先行版が掲載されています。記事や社内メモには、設定名だけでなく確認日と版番号も残すと、後から挙動を比べられます。

9月30日公開の0.159.3では、ChatGPTでサインインしたローカルセッション向けのアカウント保護設定に関する案内が変更点として記載されています。9月29日公開の0.159.2では、WindowsでCodexが裏側の処理を起動するときにコンソール画面が一瞬表示される問題の修正が案内されました。これらはworkspace-writeの許可範囲そのものを変える発表ではありませんが、Windows利用者が「更新後に見え方が変わった」と感じたとき、版と権限を別々に確認する手掛かりになります。出典 URL: https://github.com/openai/codex/releases

安定版0.159.3と先行版0.161.0-alpha.8を分ける

安定版は普段の作業で再現性を優先したいときの比較対象です。先行版は新しい変更を早く試せる一方、表示や対応する設定が変わる可能性があります。版番号が大きいことだけを理由に先行版へ切り替えるのではなく、まず安定版で現在の設定と期待する結果を記録し、その後に同じフォルダーと同じ依頼で差を見ます。

比較するときは、モデルの応答だけでなく、編集できたパス、承認が出た場面、通信の成否、確認後に残った差分を記録します。設定の問題をモデルの性能の問題と混同しにくくなるためです。公式リリースの本文で変更点が空欄の先行版については、推測で機能を追加せず、手元で確認できた事実だけを記録します。

更新後に設定も読み直す理由

Codexの設定は、CLIの引数、ユーザー設定、プロジェクト単位の設定、管理者が定めた制約など複数の場所から影響を受けます。版を更新した直後に書き込みが拒否された場合、権限を全面的に広げる前に、読み込まれている設定ファイルと作業場所を確認します。公式リファレンスには、sandbox_modeとsandbox_workspace_write配下の項目が別々に記載されています。

設定を読んだ日と版番号をセットで残しておけば、「以前は書けたのに」という現象も調べやすくなります。更新前後で同じ小さなファイルに変更を加え、差分を確認するだけでも、ファイル境界、承認の表示、通信の扱いを分けて見られます。大きなリポジトリ全体で試す前に、小さな確認対象を用意することが大切です。

workspace-writeを選ぶ前に決める三つの境界

workspace-writeの設定値を先に決めるのではなく、依頼したい作業を三つの境界に分けると迷いが減ります。第一は変更してよいファイルの範囲、第二は外部通信の要否、第三は人が内容を確認してから実行したい操作です。この順番で考えると、書き込みが必要だからといって通信まで許可したり、通信が必要だからといって別のフォルダーまで書けるようにしたりする誤りを避けられます。

三つの境界は、作業の前後で見直すことも大切です。調査だけの段階ではread-onlyで足りても、修正を保存する段階ではworkspace-writeが必要になります。反対に、変更が終わって内容を確認する段階では再びread-onlyへ戻せます。モードを目的に合わせて切り替える前提を持つと、設定を広いまま放置せずに済みます。

変更対象のフォルダーを先に決める

まずCodexに読ませるリポジトリのルートを一つ選びます。親ディレクトリ全体を指定すると、関係のない設定や別プロジェクトまで参照対象に入り、返答の前提も差分の確認範囲も広がります。Windowsではエクスプローラーに表示された場所と、ターミナルが実際に開いている場所が異なることがあるため、起動前に現在の場所を確認します。

複数のリポジトリにまたがる作業では、最初から広い場所を指定するより、主となるリポジトリで調査し、必要なファイルだけを別の依頼で扱う方が境界を説明しやすくなります。別の場所に書き込む必要があるなら、そのパスが本当に必要か、成果物を手で確認してから移すべきかを決めます。

通信が必要な作業を分けて考える

workspace-writeと通信許可は同じものではありません。設定リファレンスでは、workspace-write内の外向き通信を許可する項目としてsandbox_workspace_write.network_accessが独立して記載されています。コードの読み取りや既存ファイルの置換だけなら、通信を使わない設定のまま進められる場合があります。外部の資料を参照する、パッケージの情報を取得する、リモートの状態を確認する、といった依頼では、通信先と必要な時間を先に限定します。

通信が失敗したときに、すぐ認証やアカウントの問題と決めつけるのは危険です。書き込みは許可されていても通信が許可されていない状態があるため、まずsandboxの通信設定、次に接続先、最後に利用者側の接続設定を確認します。エラー文だけで全権限へ切り替えず、読み取り・書き込み・通信の三つを別々に戻していくと原因を見つけやすくなります。

承認を残す場面を決める

approval_policyは、Codexがコマンドを実行する前に確認を求めるタイミングを決めます。公式リファレンスでは、対話的な作業にはon-request、対話を止めずに進める用途にはneverなど、複数の選択肢が説明されています。人が画面を見ながら進める通常の開発では、書き込み範囲をworkspace-writeに保ち、重要な操作はon-requestで確認する組み合わせが考えやすいでしょう。

承認を残す対象は、単に危険そうなコマンドだけではありません。大量のファイルを変更する操作、外部へ送信する操作、別の場所へコピーする操作、削除を伴う操作は、内容と対象が人の意図に合っているかを見る価値があります。承認を減らしたいときも、先に対象のパスと確認方法を狭めてから設定を調整します。

Codex CLIでworkspace-writeを指定する手順

CLIから使う場合は、作業場所、sandboxモード、承認方針を同じ記録に残します。以下は手元のリポジトリを変更しながら、境界を越える操作では確認を求める例です。実際の版で利用できるオプション名は、まずcodex --helpと公式CLIドキュメントで照合してください。版更新によって短縮形や表示が変わる場合でも、設定名の意味を確認してから使うことが重要です。出典 URL: https://developers.openai.com/codex/cli

ここで示すコマンドは、権限を広げるための近道ではなく、現在の作業場所で変更を試すための基準です。実行前に対象パスを確認し、実行後に差分を確認するところまでを一つの手順として扱います。外部通信や別の保存先が必要なら、最初の例へ追加せず、必要性を確認したうえで別の設定として試します。

Step 1: 対象フォルダーを決める

Codexを起動する前に、今回変更してよいリポジトリだけを作業場所にします。WindowsのPowerShellならGet-Locationで現在地を確認し、表示されたパスが対象のルートかを見ます。別のプロジェクトが入った親フォルダーをそのまま作業場所にしないことが、最初の境界になります。

Step 2: workspace-writeと承認を指定する

対話的に使うなら、次のようにworkspace-writeとon-requestを同時に指定します。

codex --sandbox workspace-write --ask-for-approval on-request

この例で重要なのは、workspace-writeが書き込み場所を定め、on-requestが境界を越える処理を確認する役割を持つことです。コマンドを実行しただけで、作業場所の外や通信まで自由になるわけではありません。表示された許可内容が依頼と一致しているかを毎回読みます。

Step 3: 設定ファイルへ固定する

毎回同じ条件で確認したい場合は、Codexの設定ファイルに次のような値を置きます。network_accessは外部通信が必要な作業だけで明示的に切り替え、不要ならfalseのままにします。

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

追加の書き込み先が必要な場合も、writable_rootsへ広い親フォルダーを入れる前に、実際に保存するディレクトリを一つずつ確認します。設定の置き場所や優先順位は、Codex Configuration Referenceの説明に合わせてください。

Step 4: 小さな変更で境界を確かめる

最初から大規模な修正を頼まず、対象リポジトリ内の短い文書やテスト用の小さな変更で、読み取り、書き込み、差分表示の順に確認します。Codexの返答だけで完了と判断せず、ファイルの更新時刻と差分を人が読みます。意図しないパスに変更がないことも、同じ確認に含めます。

Step 5: 通信を必要とする場合だけ広げる

依存関係の情報やリモートの資料が必要になった場合は、現在の依頼に本当に通信が必要かを先に確認します。必要ならnetwork_accessを有効にした設定を短い作業だけで試し、通信先と結果を記録します。書き込みが成功しても通信が失敗する場合は、workspace-writeそのものが壊れたと決めつけず、二つの設定を分けて調べます。

config.tomlで書き込み範囲を狭める考え方

設定ファイルを使う利点は、毎回の入力を減らすことではなく、同じ作業場所で同じ境界を再現しやすくすることです。ただし、設定を固定したからといって、すべてのリポジトリに同じ値が適するわけではありません。個人用の設定とプロジェクト用の設定を分け、対象プロジェクトを変えたら、書き込み先と通信の要否を読み直します。

公式リファレンスでは、sandbox_modeにread-only、workspace-write、danger-full-accessがあり、workspace-writeの補助設定としてnetwork_accessとwritable_rootsが示されています。ここから分かるのは、権限を一つの大きなスイッチで扱うのではなく、ファイルの場所と通信を別々に組み立てる設計です。設定名が似ていても、役割を混ぜないことがトラブル防止になります。出典 URL: https://developers.openai.com/codex/config-reference

writable_rootsを追加するときの確認

writable_rootsは、workspace-writeの対象に追加したい書き込み先を表します。追加が必要な例として、成果物を専用の出力フォルダーへ置く場合があります。しかし、ドライブのルート、ユーザーフォルダー、複数プロジェクトの共通親を指定すると、依頼の範囲を超えて変更できる余地が大きくなります。

追加する前に、必要なファイルが現在の作業場所へ移せない理由を確認します。移せるなら追加をやめ、作業場所を見直す方が単純です。移せない場合は、最も深いディレクトリを選び、そこに意図した成果物だけが残るかをテストします。設定にパスを追加した後は、Codexの権限表示と実際の差分を照合します。

network_accessを追加するときの確認

network_accessは、workspace-writeで外向き通信を使うかどうかの項目です。ネットワークが必要な理由が「依存関係の取得」なのか「外部資料の参照」なのかで、確認すべき結果が違います。目的を一文で書けないなら、まず通信なしで調査を進め、足りない情報を特定してから設定を変える方が安全です。

通信を許可した後は、どのコマンドが接続を行ったか、どの結果をファイルへ保存したかを確認します。取得した内容をそのまま信頼せず、変更対象と差分を読んでから次の依頼へ進みます。通信を許可した設定を普段の既定値にする必要がなくなったら、falseへ戻すことも確認項目に含めます。

Windowsでworkspace-writeが動かないときの切り分け

Windowsで「書き込めない」と表示された場合、最初にファイルの読み取り専用属性やWindows側のフォルダー権限だけを疑うと、原因を見誤ることがあります。Codexの作業場所、sandbox_mode、実行を求められた操作、CLIの版番号が別々に関係するからです。表示されたエラーと実際の差分を保存し、どの段階で止まったかを一つずつ確認します。

確認の順番は、作業場所、Codexのモード、OS側の状態、CLIの版番号とすると整理しやすくなります。パスを直せば解決する問題に全面アクセスを選んだり、通信の失敗をファイル権限の問題として扱ったりしないためです。小さなファイルで同じ操作を再現し、変更できた範囲と止まった操作を分けて記録します。

パスの問題と権限の問題を分ける

Codexが変更しようとしたパスが作業場所の外なら、workspace-writeの境界に当たっている可能性があります。まず依頼したファイルの絶対パスと、Codexを起動した場所を比較します。意図した場所が同じリポジトリ内なら作業場所を直し、別の場所なら追加の書き込み先が本当に必要かを検討します。

作業場所の内側なのに失敗する場合は、Windowsのファイル属性、別のアプリによるロック、読み取り専用の共有フォルダーなどを調べます。いきなり全面アクセスへ変更せず、手動で同じフォルダーへ小さなファイルを書けるかを確認すると、Codexの境界とOS側の状態を分離できます。

版番号と起動場所を照合する

Codex CLIを更新した後は、codex --versionの表示と公式リリース一覧を照合します。安定版と先行版を入れ替えた直後なら、設定ファイルを同じままにして、同じ小さな作業を試すのが比較の起点になります。前の版で動いたという記憶だけでは、現在の設定や起動経路まで同じだとは限りません。

Windowsのデスクトップアプリ、PowerShellから起動したCLI、WSLから起動したCLIでは、作業場所や利用するsandboxの層が異なることがあります。見た目が同じCodexでも、どの入口で動かしたかを記録します。公式のWindows sandbox案内も確認し、OS側の対応とCLIの設定を一緒に判断しないようにします。出典 URL: https://developers.openai.com/codex/cli

通信失敗を認証失敗と混同しない

コードの変更はできるのに、リモートの情報取得だけが失敗するなら、まずnetwork_accessの状態を見ます。workspace-writeはファイルの書き込みを許可する設定であり、通信の許可を意味しません。通信の境界、接続先の状態、アカウントの接続設定をこの順番で確認すると、不要にファイル権限を広げずに済みます。

通信を使わない依頼へ戻す場合は、既に取得した資料や差分を確認し、network_accessをfalseに戻してから続けます。通信のために広げた設定をそのまま残さないことも、workspace-writeを長く使ううえで大切な管理です。

変更結果を確認する読み方

workspace-writeを選んだ目的は、Codexが書き込みを行うことそのものではなく、必要な変更を人が理解できる形で残すことです。作業終了時は、返答の要約、実際の差分、確認に使ったコマンドの結果を別々に読みます。要約に問題がなくても、意図しないファイルの変更や、説明に出ていない生成物が残っていないとは限りません。

確認の対象は、変更されたファイルだけではありません。作業場所の外へ新しいファイルが作られていないか、通信を許可した場合に不要な取得結果が残っていないか、承認を求められた操作が依頼の範囲に収まっているかも見ます。書き込みを許可した範囲が狭くても、結果を読まずに次へ進めば判断材料を失います。

差分と確認結果を別々に見る

まず変更されたファイルの一覧を確認し、次に各差分の内容を読みます。新規ファイルは内容だけでなく、保存された場所と名前が依頼に合っているかを見ます。既存ファイルは、変更前の意味を壊していないか、行末や文字コードが意図せず変わっていないかを確認します。

その後で、テストや静的チェックの結果を読みます。確認が成功しても、変更範囲が広すぎる問題は別に残ります。反対に、確認が失敗しても、その失敗が今回の変更によるものか、元からある条件によるものかを分けて記録します。Codexに再修正を頼むときは、差分と失敗した確認を具体的に示すと、書き込み範囲を広げずに済みます。

read-onlyへ戻す基準を持つ

実装が終わった後に調査や説明だけを頼むなら、read-onlyへ戻す選択があります。変更が不要な場面でworkspace-writeを維持する理由はありません。モデルやCLIを試すために既存コードを読む場合も、まず読み取り専用で対象と前提を確認し、保存が必要になった時点でworkspace-writeへ移ると、意図しない更新を見つけやすくなります。

版更新の確認でも、最初はread-onlyで現在の設定を読み、次に小さな作業だけworkspace-writeで試す流れが適しています。モードを戻す判断を決めておけば、テストが終わった後も広い設定を残さずに済みます。

まとめ

Codex workspace-writeは、リポジトリ内のコードを調査し、必要な変更を保存するための現実的なsandboxモードです。作業場所の外へ書き込める設定でも、通信を許可する設定でもありません。read-only、workspace-write、全面アクセスの違いを確認し、最も狭い範囲で目的を満たすものを選びます。

2026年10月1日時点では、公式リリース一覧に安定版0.159.3と先行版0.161.0-alpha.8が並んでいます。版を更新したら、作業場所、writable_roots、network_access、approval_policyを分けて読み、同じ小さな差分で結果を比べてください。書き込み範囲と通信範囲を先に限定し、最後に変更と確認結果を人が読むことが、workspace-writeを安心して使い続けるための基本です。