Codexフルアクセスの意味と承認設定の違い・使う前の確認

Codexフルアクセスで変わるファイルと通信の範囲

OpenAIの権限モードの公式説明では、Full accessを、端末上の任意のファイルとインターネットへ制限なくアクセスできるモードとして案内しています。ここで注目するのは「端末上の任意のファイル」という範囲です。編集中のプロジェクトだけに対象が限定される設定とは、許可する作業の広さが異なります。

ただし、この説明を、端末や組織が持つすべての制限を解除するという意味には読まないでください。利用者が持つOS上の権限、管理された端末の条件、サービス側の制限などは別に存在します。フルアクセスを選んだだけで、利用者自身が開けないファイルまで必ず編集できる、別のコンピューターへ接続できる、といった保証にはなりません。

通常の開発作業では、依頼したファイル以外にも関連資料を読む必要があります。そこで問題になるのが、必要な資料の場所と、書き換えてよい場所の違いです。別フォルダの仕様書を一度読むために、端末全体の編集範囲まで広げる必要があるかは個別に判断できます。必要な入力資料を作業フォルダへ用意する方法も含めて、目的からアクセス範囲を決めると整理しやすくなります。

本記事で扱うフルアクセスは、利用者が自分のCodexの権限を選ぶ場面の話です。実際に表示される選択肢は、アプリの版、実行環境、ローカルの設定、組織の要件によって変わります。公式資料も、使えないモードが非表示や無効になる場合を説明しています。画面に選択肢がないときは、その環境で許可されている範囲を先に確認します。

承認の回数とアクセス範囲を分けて考える

Codexの権限は、技術的に何へアクセスできるかを定めるサンドボックスと、どの場面で確認を求めるかを定める承認ポリシーの組み合わせで決まります。この二層の考え方は、エージェントの承認とセキュリティに関する公式資料に明記されています。確認の表示が少ないという見た目だけでは、許可された範囲を判断できません。

たとえば、作業フォルダの範囲を保ったまま承認要求を出さない設定では、範囲外の操作が必要になっても、その場で利用者へ許可を求めて進むことができません。確認が出ないことは、操作が成功することを意味しません。逆に、広いアクセスを持つ設定では、利用者が想像していた作業フォルダ以外へ影響が及ぶ可能性を考える必要があります。

CLIの設定名では、sandbox_modeがアクセス範囲、approval_policyが確認の条件に対応します。公式資料は、--ask-for-approval neverを複数のサンドボックス設定と組み合わせられると説明しています。したがって、承認要求を止める指定と、danger-full-accessによって範囲を広げる指定は、同じ操作として理解しないことが大切です。

依頼文で「このフォルダだけを直してください」と伝えることも有用ですが、文章で示した希望と技術的な境界は役割が違います。依頼文には目的と対象を明記し、権限設定では実際に許す範囲を確認します。両方を揃えることで、意図の取り違えにも、予期しない操作にも備えやすくなります。

三つの権限モードは何を確認する仕組みか

公式の権限ページは、多くの作業ではAsk for approvalから始めるよう案内しています。このモードでは、現在の作業フォルダの中で作業を進め、境界を越える必要がある場面で確認を求めます。コードの調査、対象ファイルの修正、テストの実行といった依頼を、まずこの範囲で完了できるか見るのが判断の出発点になります。

Approve for meは、Ask for approvalと同じworkspace-writeの境界を保ち、対象となる承認要求を審査へ送る仕組みです。審査に回すことと、端末全体へのアクセスを与えることは違います。確認への応答が多いと感じたときは、その原因が操作の内容にあるのか、作業場所にあるのかを調べると、必要な設定を選びやすくなります。

この表はモードを選ぶための整理であり、すべての機能や接続先へ同一の権限が適用されるという意味ではありません。公式のセキュリティ資料は、外部アプリの操作にも別の承認が発生し得ると説明しています。ファイル編集の権限を変えた後も、外部サービスでの操作は、そのサービスの確認表示と許可内容を読んで判断する必要があります。

10月の承認案内改善を権限の変更と混同しない

公式変更履歴の2026年10月8日付項目では、Codex app 26.1007について、ツールの操作に承認が必要なのに、チャットの権限が承認要求を許さない場合の回復案内を改善したと記載しています。可能な場合には、その権限へのリンクも表示されます。これは、止まった理由と見直す場所を理解するうえで役立つ更新です。

この案内が出たとき、利用者がまず確認したいのは、何をするために追加の許可が必要になったのかです。作業フォルダ外のファイルを書き換えたいのか、テストに必要な接続を開きたいのかによって、対応は変わります。単に「進まないからフルアクセスにする」と決めると、必要な範囲と選んだ範囲が合わなくなる場合があります。

更新履歴の記述は、すべての環境で承認が必ず可能になったという説明ではありません。現在のチャットや組織の条件によっては、利用者が変更できないこともあります。その場合は、必要な操作、表示された制約、対象フォルダを整理し、管理者へ確認できる形にします。許可の根拠が分からないまま、別の入口へ切り替えて同じ操作を試し続けるより、判断材料を揃えたほうが原因を見つけやすくなります。

2026年10月16日時点で重要なのは、案内の改善を、既存の権限が広がった証拠として扱わないことです。更新後も、現在選ばれているモードと、対象の作業で必要な権限を照合する作業は残ります。

フルアクセスを選ぶ前に進める確認手順

フルアクセスが適切かどうかは、依頼の大きさより、必要な操作の範囲で判断できます。数行の修正でも端末全体へ影響するコマンドを含む場合があり、反対に大きなコード修正でも、一つの作業フォルダの中で完結する場合があります。以下は、本記事で提案する確認手順です。公式のボタン操作を再現したものではなく、設定を選ぶ前の判断を揃えるための順序です。

1. 対象の作業フォルダと、成果物を保存する場所を確認します。似た名前のフォルダが複数ある場合は、実際に開いている場所まで確かめます。
2. フォルダ外で必要な操作を列挙します。読むだけの資料と、編集が必要なファイルを分け、対象を指定できる形にします。
3. 外部通信が必要な理由を確認します。ライブラリの取得や接続確認など、何に接続し、何を送る必要があるかを書き出します。
4. 通常の権限で完了できる範囲を確認します。操作を分割したり、必要な資料を用意したりすることで、広い権限が不要になる場合があります。
5. 広い権限を使うと判断したら、変更前の状態へ戻す方法と、作業後に確認する対象を決めます。組織で管理された端末では、利用者が変更できる条件も確認します。

コードの修正なら、変更前の内容を比較できるようにしておくと、作業後のレビューが具体的になります。ただし、ファイルの比較で分かるのは主に保存された変更です。外部への送信や別サービスでの更新まで、ファイルを戻すだけで取り消せるとは限りません。通信とローカル編集は、確認する記録も戻し方も分けて考えます。

依頼時には「問題を直す」という目的に加えて、編集対象、触れてよい場所、作業後に報告してほしい内容を伝えます。権限を広げる場合ほど、何をもって完了とするかを狭く明確にしておくと、結果を評価しやすくなります。

設定の切り替え後は現在のチャットで確かめる

公式の権限ページによると、デスクトップアプリやIDE拡張では入力欄の下にある権限のコントロールを使い、CLIでは/permissionsを入力して設定を確認できます。設定の選択肢が表示されることと、そのモードが現在のチャットで選ばれていることは別です。切り替えたつもりで作業を続けず、対象のチャットで現在値を読みます。

CLIでは/statusによって作業範囲に含まれるディレクトリを確認できると、公式のセキュリティ資料が説明しています。設定名と作業場所を併せて見ることで、「意図したプロジェクトの中で動いているか」を確認できます。画面上の権限名だけを見て、対象フォルダまで正しいと推測しないことがポイントです。

切り替えを確かめるために、大きな削除や外部への送信を試す必要はありません。まず必要な資料を読めるか、対象のファイルへ小さな変更を保存できるかなど、今回の依頼に直接関係する範囲を確認します。予想と違う動きが出たら、実際の操作、表示されたエラー、現在のモードを揃えて見直します。

設定を変更できない場合は、組織の要件や実行環境による制約も候補になります。公式資料は、モードの利用可否がそれらの条件に依存すると説明しています。利用者の希望だけでは変えられない設定もあるため、表示されている事実を基準に判断します。

作業後は権限を戻し成果物と接続先を確認する

広いアクセスが必要な作業を終えたら、そのチャットの権限を通常の運用に戻し、現在値を確認します。権限を戻す操作は、次の操作へ適用する境界を整えるためのものです。すでに変更したファイルや、外部へ送信した情報が、それによって元に戻るわけではありません。作業結果の確認は別に行います。

レビューでは、依頼したファイルの差分、追加されたファイル、削除された内容を読みます。対象外のフォルダを扱った場合は、その場所で何をしたかも報告に含めます。テストが成功したかどうかに加えて、実行できなかった確認や、環境の制約で残った作業があるかを確かめると、完了の意味が明確になります。

外部通信を許した場合は、接続の目的と実際の送信内容が依頼に合っていたかも確認します。必要なら、Codexに作業中のコマンドや接続先を説明させ、その説明を利用可能な記録と照合します。説明があることだけで、すべての操作を確認できたとは判断せず、把握できる範囲を明らかにしておきます。

フルアクセスを選ぶ基準は、確認を省けるかより、作業に必要な範囲を理解できているかです。通常の作業フォルダで進められる部分、追加の許可が必要な部分、作業後に戻す部分を決めておけば、権限設定と成果物のレビューを結び付けられます。設定の意味を確認したうえで、今回の依頼に必要な範囲を選びましょう。