Codexの権限と承認設定を理解する：小さな作業範囲から始める方法

要約： Codexの権限はアクセス可能なファイル・ネットワークの境界と、その境界を越える際の承認方法に分けると理解しやすくなります。まず作業フォルダーと結果を定め、読み取り、変更、インストールに必要な範囲を選んでください。承認の質問が減ってもアクセス範囲が狭まるわけではなく、広い権限を与えてもコードの品質がよくなるわけではありません。

1. 三つの設定を区別して読む

OpenAIの公式Sandbox文書では、サンドボックスはコマンドのファイル・ネットワークアクセスの境界で、承認ポリシーは追加承認を求める時点を定めます。承認の審査担当は、依頼を利用者か自動審査担当かの誰が判断するかを定めます。自動審査を選んでも既存のサンドボックスの境界は自動的に広がりません。

実務では「どこにアクセスできるか」「阻止された行動を申請できるか」「誰が判断するか」の三問で読んでください。例えばプロジェクト内の文章修正は現在の境界内で可能でも、別リポジトリの資料取得や依存関係のダウンロードには別のアクセスが必要な場合があります。実際の可否は現在適用される設定で確認する必要があります。

プロンプトの「このフォルダーだけ変更する」は作業指示です。技術的なファイル遮断と同じ意味ではありません。逆に読み取り専用で実行し「ファイルを直接直して」と書いても、指示だけで書き込み権限は生じません。作業範囲を言葉で定め、実際の権限設定が合うか確認する二段階が必要です。

2. 作業に合わせて範囲を選ぶ表

以下は執筆者が構成した選択基準です。全環境の既定値を説明する表ではなく、今回必要なアクセスを判断する案内です。開始時は成果物を一つに絞り、途中で分かった必要性に応じて範囲を調節してください。

求める結果	まず必要な範囲	追加アクセスを判断するとき
コード構成とエラー原因の説明	関連ソースと設定の読み取り	存在しないファイルを読んだと仮定しないか確認
検索入力の不具合修正	関連プロジェクトファイルへの書き込みとローカル検証	テストが作るキャッシュ・結果ファイルの場所の確認
新しいパッケージのインストール	インストール対象ファイルの変更と必要なネットワーク	対象パッケージ、ダウンロード元、インストールスクリプトの確認
別リポジトリの共通モジュールの比較	そのリポジトリの必要ファイルの読み取り	両リポジトリ全体への書き込みが必要か区別
外部サービスへの結果公開	サービス接続と該当する書き込み作業	草案作成と実際の公開の対象・権限を区別

プロジェクトフォルダーはソース、設定、必要なテストが入る最も近い共通フォルダーを基準に選んでください。文書フォルダー全体や複数顧客のプロジェクトを開くと、無関係な資料も作業の文脈に入ることがあります。共通モジュールが外にある場合は必要ファイルを読ませるか、別プロジェクトとして扱うかを先に決めればよいでしょう。

読み取り専用の調査でも結果の保存先を定める必要があります。「確認だけして」と言いながらローカル報告ファイルを求めれば書き込みが必要です。画面の説明とファイルの報告を区別して依頼すれば、設定の選択ミスを減らせます。

3. アプリ・CLIで実際の設定を確認する

公式の権限モード文書は、通常の作業はAsk for approvalから始めるよう案内しています。このモードは作業領域内の読み取り・変更と通常のローカルコマンドを許可し、境界を越える作業は申請します。デスクトップアプリとIDEは入力欄下の権限メニュー、CLIは/permissionsを使います。CLIの/statusで作業領域も確認できます。

デスクトップアプリで追加モードが見えなければ、現在の文書のSettings > General > Permissionsを確認してください。メニューにモードを表示させることと、現在の会話で選択することは異なります。組織のポリシーで選択が制限されることもあります。メニュー名を見つけただけで既存会話の権限が変わったと判断しないでください。

CLIで意図を明示して開始するには下記の公式対応オプションを使えます。一行目は読み取り中心の調査、二行目はプロジェクト変更の例です。二行を連続実行する手順ではなく、作業に合う一行を選ぶ例です。

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

公式の承認・セキュリティ文書は、これらの組み合わせと保護されたパスを説明しています。workspace-writeでも.git、.agents、.codexなどには別の保護があります。そのため作業フォルダー内というだけで全設定ファイルへの書き込みが許可されると仮定してはいけません。

設定ファイル記述で混乱しやすい点

既存のサンドボックス方式のプロジェクト変更の既定値を表す小さな例は次の通りです。実際の設定ファイル全体をこの内容で上書きする意味ではありません。既存設定と組織の要件を確認し、適用する項目だけを判断してください。

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

現在の権限プロファイル文書にはベータ方式のdefault_permissionsと[permissions]もあります。これは既存のsandbox_mode方式と組み合わせて適用する設定ではないため、異なる例を混ぜないでください。新しいプロファイルを使うなら、先に文書の互換条件を確認するとよいでしょう。

Windowsもネイティブサンドボックスと権限プロファイルに対応しています。エラーだけでWSLが必須と断定せず、実行中の環境と適用ポリシーから確認してください。同じPCでもネイティブWindows作業とWSL内の作業はパスとインストール済みツールが異なることがあります。

4. コピーして変更する事前確認プロンプト

次は執筆者が構成した架空の検索アプリの作業例です。角括弧を自分のパスと要求に置き換えてください。最初は資料を読み、必要なアクセスを説明させ、作業準備の状態を把握するために使えます。

작업 목표: [검색어 앞뒤 공백 때문에 검색이 실패하는 원인 설명]
대상 프로젝트: [실제 프로젝트 경로]
조사 범위: [검색 입력 컴포넌트, 호출 함수, 관련 테스트]
현재 작업 폴더와 확인 가능한 권한 설정을 알려 주세요.
먼저 관련 파일을 읽고 원인 후보와 근거 위치를 정리해 주세요.
이 단계의 결과는 대화에 작성해 주세요.
추가 접근이 필요하면 대상 경로·서비스, 목적, 예상 변경을 설명해 주세요.
확인하지 못한 설정이나 자료는 미확인이라고 표시해 주세요.

この依頼で得るのは「全権限が安全」という宣言ではなく、必要ファイルと検証方法の一覧です。検索コンポーネントを読んでも原因が見つからなければ、実際のエラーメッセージや要求データが追加で必要かもしれません。その際は個人情報を除いた再現入力を提供すれば、広いファイルアクセスなしでも調査に役立ちます。

作業を実行するときは希望動作と完了基準も加えてください。次の文は範囲指示の例で、アプリの権限設定は変更しません。

수정 목표: [검색어 앞뒤 공백만 제거하고 기존 검색 동작 유지]
수정 대상: [확인한 파일과 관련 테스트]
기존 API 요청 형식과 다른 화면의 동작을 유지해 주세요.
프로젝트에 이미 설치된 도구로 관련 검증을 진행해 주세요.
추가 설치가 필요하면 패키지·출처·파일 변경·설치 스크립트를 설명해 주세요.
최종 결과에 수정 파일, 실행한 명령, 결과, 미실행 검증을 적어 주세요.

5. 承認依頼を読む五つの質問

承認画面ではコマンド名だけでなく、入力と結果の行き先を読んでください。「依存関係のインストール」という目的が同じでも、プロジェクト内にファイルを作るインストールとグローバルツールのインストールでは変更位置が異なります。ダウンロード資料が単なるデータか、実行するスクリプトかも判断に役立ちます。

1. 対象： どのフォルダー、ホスト、リポジトリ、サービスにアクセスするか？
2. 入力： どのファイルや値を読み、または送信するか？
3. 変更： 何を作成・修正・削除するか？
4. 必要性： 現在の要求を解決するため、なぜこの行動が必要か？
5. 範囲： 一度、今回の作業、セッションのどの範囲で許可するか？

説明が不足すれば「このコマンドのファイル変更、外部通信、インストール後に実行するコード、より小さな代案を説明して」と頼んでみてください。承認画面が示す範囲から作業完了に十分なものを選べばよいでしょう。同じ依頼が繰り返す場合は無条件に広く許可するより、承認対象が毎回変わるか確認してください。

自動審査も判断を誤る場合があります。承認済みは審査に合格した意味で、実行成功や結果の正確性を保証しません。承認されたインストールが失敗したら、次にログとファイル状態を読む必要があります。同じコマンドを再申請するだけで原因は解決しません。

6. 行き詰まったときの原因を分ける表

見える症状	最初に確認すること	次の措置
ファイルが見つからない	誤字、相対パスの基準、実際のファイルの存在	正確なパスを確認し、読むファイルを指定する
アクセス拒否	読み書きの区別、作業境界、OS権限	失敗対象と必要アクセスだけを再判断する
インストールのダウンロード失敗	遮断メッセージ、DNS・プロキシ・リポジトリの応答	ネットワークポリシーとサービスのエラーを分ける
テストコマンド失敗	実行ファイルの存在、依存関係、実際のテストエラー	ツール準備の問題とコードの失敗を分けて記録する
権限モードを選べない	組織の要求と現在の設定	許可範囲で可能な作業から進める

例えばテストが一時ファイルへの書き込みで失敗したら、ソース修正の権限だけでは不足する場合があります。必要な書き込み場所を確認し、プロジェクト内の結果パスを使えるか検討してください。逆に期待値の不一致で失敗したなら権限を広げても解決しません。失敗メッセージのどの部分がアクセス制限を意味するかから区別する必要があります。

approval_policy = "never"は承認の質問をしない意味で、サンドボックス解除の意味ではありません。境界外の行動は失敗し得るため、自動実行でも必要なアクセスと失敗報告を設計する必要があります。Full accessは広範なファイル変更とネットワーク実行を可能にするため、エラー解決の基本選択にしないでください。

7. 作業後は権限より結果を検証する

修正後は依頼したファイルと実際の変更ファイルを先に比較してください。想定外のロックファイル、設定ファイル、生成ファイルがあれば変更理由を確認します。利用者が既に編集していた変更と今回の変更も分ける必要があります。変更一覧が小さくても主要動作を検査しなければ、完了の根拠が不足する場合があります。

• 問題の入力と正常入力をそれぞれ確認したか？
• 報告されたコマンドは実行済みで、結果が残っているか？
• 失敗した検証と実行できなかった検証が別々に表示されたか？
• 外部公開やインストールの対象と結果は依頼に合うか？
• 追加アクセスを一時許可した場合、適用範囲は終了したか？

架空の検索アプリなら、空白のある「 金属 」、ない「金属」、空白だけの入力で期待動作を定義できます。修正ファイルと検証結果を一緒に見ると、アクセスの許可と要求の解決を混同せずに済みます。この記事の例は説明用で、そのプロジェクトを実行・テストした事例ではありません。

8. 最初に始める際の実用的な手順

プロジェクトフォルダーを確認し、読み取りか修正かの目的を定めて現在の権限を確認してください。必要な行動が境界を越える際は対象と目的を読み、追加範囲を判断します。最後に変更ファイルと検証結果を確認してください。この順序を覚えると権限メニューで最大範囲を選ぶ代わりに、今回必要なアクセスを説明できるようになります。

公式の出典と確認日： 権限モード、 サンドボックス、 承認・セキュリティ、 権限プロファイル。2026年10月3日確認。設定例は現在の環境と組織のポリシーに合わせて調整してください。