Codex permissionとは？許可設定の方法や自動承認の注意点も解説
Codexのpermissionって何のためにあるの？
毎回の許可がめんどくさいけど、自動承認にしても大丈夫なのかな…
Codexを使い始めてから「permission」という言葉を聞く機会が増え、どんな機能か気になっている人は多いですよね。
構成要素やできることなど、詳細を把握してから使うべきかを決めたい人もいるはず。
そこでこの記事では注意点も交え、Codex permissionの特徴を解説します。設定方法や使い方も紹介するので、ぜひ参考にしてください。
Codexの特徴を詳しく知りたい人は、次の記事を参考にしてください。
- Codex permissionはサンドボックスと承認ポリシーを組み合わせて操作範囲を制御する
- 承認を減らす設定は便利だが信頼できるプロジェクトや作業環境で利用することが重要
- AGENTS.mdを使えばプロジェクト固有のルールや開発上の注意点をCodexに継続的に伝えられる
『ClaudeCodeに興味はあるけど、どうやって使えばいいんだろう…』
そんな方へ、
- ClaudeCodeに作業や仕事を任せる方法
- ClaudeCodeを使いこなすたった1つのコツ
- 業務効率化や収入獲得に活かすClaudeCodeの実演
を、無料のオンラインセミナーで凝縮してお伝えします！
パソコンはもちろん、スマホから気軽に参加OK。この時間が、あなたを変える大きなきっかけになりますよ。
Codex permissionとは？
Codex permissionとは、Codexがファイルを編集したり、コマンドを実行したりする際の権限や承認方法を制御する仕組みです。AIエージェントにどこまで操作を許可するかを設定することで、意図しない変更や危険な操作を防ぎやすくなります。
ここからはCodex permissionが必要な理由と管理できる操作範囲を解説します。
必要な理由
Codex permissionが必要な最大の理由は、AIエージェントによる操作の範囲を適切に制御するためです。
Codexはコードの生成だけでなく、ファイル編集やシェルコマンドの実行もできます。便利な反面、権限を広く設定しすぎると次のようなリスクが生じます。
- 重要な設定ファイルを意図せず変更する
- 不要なコマンドやパッケージを勝手にインストールする
- ネットワークを介した操作を許可してしまう
そこでCodexでは、サンドボックスによってファイルシステムやネットワークへのアクセス範囲を制限し、承認ポリシーによってユーザーへの確認が必要な操作を制御します。
たとえば、開発中のコードを編集する作業ではある程度の自動化を許可しつつ、外部への変更やリスクの高い操作では確認を求める、といった使い分けが可能です。
そのため、Codexを安全かつ効率的にに活用するには、作業内容に応じて適切なpermission設定を選ぶことが重要です。
管理できる操作範囲
Codexの権限設定では、主にファイル操作・コマンド実行・ネットワークアクセスなどの範囲を制御できます。
具体的には次の操作を制御できます。
- ファイルやディレクトリの読み取り・書き込み・削除
- シェルコマンドの実行（npm install、git pushなど）
- ネットワークへのアクセス（外部APIの呼び出しなど）
ファイル操作については、読み取りだけを許可して書き込みは禁止する設定が可能です。コマンド実行では、特定のコマンドだけを許可リストに追加できます。
ただし、これらをすべて個別に許可リストへ登録するというより、サンドボックスモードと承認ポリシーを組み合わせて操作範囲や確認の有無を決める仕組みです。
たとえばサンドボックスによって、Codexがワークスペース内のファイルを編集できるようにしつつ、ネットワークアクセスを制限できます。また、承認ポリシーによって、コマンド実行などの操作をユーザーが確認してから実行するよう設定できます。
このように、Codex permissionは操作の種類ごとにきめ細かく権限を設定できる仕組みです。Codexにどこまで操作を任せるかと、どの操作で人間の確認を求めるかを組み合わせて管理する機能と考えるとわかりやすいでしょう。
Codexのおすすめ設定を詳しく知りたい人は、次の記事を参考にしてください。
Codex permissionの構成要素
Codex permissionは「サンドボックス」と「承認ポリシー」の2つの軸で構成されています。サンドボックスはCodexがファイルやネットワークへアクセスできる範囲を制御し、承認ポリシーは操作を実行する際にユーザーの確認を求めるかどうかを決めます。
ここからは下記の構成要素別に、それぞれの種類と推奨設定を解説します。
サンドボックスモードの種類
サンドボックスモードは、Codexが実行するコマンドやファイル操作をどの範囲に制限するかを決める設定です。OpenAIの公式ドキュメントによると、主に3種類のサンドボックスレベルが用意されています。
| モード | ファイルアクセス | ネットワーク | 用途 |
|---|---|---|---|
| read-only | 読み取りのみ | 制限あり | コードの確認・レビュー |
| workspace-write | ワークスペース内で読み書き可能 | 制限あり | 日常的な開発作業 |
| danger-full-access | 制限なし | 制限なし | 特別な事情がある自動化 |
read-onlyは、Codexによるファイルの編集を許可せず、コードの確認や分析を中心に行いたい場合に適しています。編集や制限を超える操作には承認が必要になります。
workspace-writeは、現在のワークスペース内にあるファイルの読み書きや、通常のローカルコマンドの実行を許可するモードです。ローカルでの開発作業に適した、制限と利便性のバランスが取れた設定として利用できます。
danger-full-accessは、サンドボックスによるファイルシステムやネットワークの制限を解除するモードです。Codexがより広い範囲を操作できるようになるため、必要性を十分に確認したうえで利用しましょう。
なお、サンドボックスは「安全・危険」の2択ではありません。必要な操作だけを許可し、不要なアクセスは制限するという考え方が基本です。
Codexのサンドボックスについて詳しく知りたい人は、次の記事を参考にしてください。
承認ポリシーの種類
承認ポリシーは、Codexが操作を実行する前にユーザーへどの程度確認求めるかを定める設定です。Codexでは、主に次の3種類の承認ポリシーがあります。
| ポリシー | 特徴 | 向いている場面 |
|---|---|---|
| untrusted | 信頼済みとして扱われないコマンドの実行前に確認 | 安全性を重視したい場合 |
| on-request | サンドボックス内の作業は進め、境界を超える必要があるときに確認 | 日常的な開発作業 |
| never | 承認確認を求めずに実行 | 十分に信頼できる環境での自動化 |
untrustedは、信頼済みとして扱われないコマンドを実行する前にCodexが確認を求める設定です。操作内容を確認しながら慎重に進めたい場合に適しています。
on-requestは、サンドボックスの範囲内であればCodexが自律的に作業を進め、ネットワークへのアクセスやサンドボックスの境界を越える操作などが必要になった場合に確認を求める設定です。毎回の操作を承認する手間を減らしながら、安全性も確保しやすいため、日常的なローカル開発では使いやすい設定です。
neverは、承認プロンプトで処理を停止しない設定です。自動化には便利ですが、ユーザーによる確認が入らなくなるため、サンドボックスや実行環境の安全性を十分に確認してから利用しましょう。
「許可がめんどくさいから、すべて自動承認にする」という設定は避け、サンドボックスによる制限と組み合わせて利用することが重要です。
Codexの承認モードについて詳しく知りたい人は、次の記事を参考にしてください。
2軸の組み合わせと推奨設定
サンドボックスと承認ポリシーは、それぞれ独立した設定です。たとえば、ファイルへの書き込みを許可しながら、コマンド実行時には確認を求めるといった組み合わせができます。
初心者の場合は、制限を強めたサンドボックス＋確認を求める承認設定から始めるのがおすすめです。
代表的な組み合わせと適した場面は次のとおりです。
| サンドボックス | 承認ポリシー | 特徴 | おすすめの用途 |
|---|---|---|---|
| read-only | untrusted | ファイル編集を制限し、慎重に操作 | コードレビュー・確認 |
| workspace-write | on-request | ワークスペース内は自律的に作業し、範囲外は確認 | 日常的な開発 |
| danger-full-access | never | サンドボックスと承認の制限を解除 | 特別な事情がある自動化 |
とくに、リポジトリの内容を十分に把握していない段階では、いきなり自動実行を有効にしないことが大切です。
まずは確認を求める設定でCodexの動作を把握し、問題がないことを確認してから、必要な範囲だけ自動化するとよいでしょう。
Codex permissionで権限を与える注意点
Codexに権限を与える際は、「必要な操作だけを許可する」という考え方が重要です。 便利だからといって最初から制限を緩めるのではなく、作業内容やリポジトリの重要度に応じて設定しましょう。
とくに注意すべきポイントは次の4つです。
- 自動実行を安易に有効にしない
- 重要なリポジトリではsandboxを活用する
- ネットワークやコマンドの許可範囲を必要最小限にする
- プロジェクトや運用環境が変わったら設定を見直す
自動実行を有効にすると、Codexへの確認回数を減らせるため作業効率が上がります。一方で、確認なしに操作が進むため、誤ったファイル編集や意図しないコマンド実行が発生した場合も、そのまま処理される可能性があります。
そのため、初めて使うプロジェクトや内容を十分に把握していないリポジトリでは、まず確認を求める設定から始めるのがおすすめです。動作を確認したうえで、問題のない範囲だけ自動化するとよいでしょう。
また、本番環境に関係するリポジトリや重要なデータを扱う環境では、sandbox設定を必ず有効にしましょう。sandboxが無効だと、Codexがシステム全体のファイルにアクセスできる状態になります。
なお、権限設定は一度決めたら終わりではありません。月に1回は設定内容を見直し、不要になった権限や制限の緩い設定が残っていないか、定期的に確認しましょう。
Codexの安全性・セキュリティについて詳しく知りたい人は、次の記事を参考にしてください。
Codex permissionの設定方法
Codex permissionの設定方法は複数あり、CLIフラグ・設定ファイル・プロファイル・IDE拡張の4つの手段があります。プロジェクトや作業スタイルに合った方法を選ぶことで、効率よく権限管理できます。
ここからはCodex permissionの設定方法を、4つにまとめて解説します。
CLI起動時のフラグ指定
もっとも手軽な設定方法は、CLIの起動時にオプションを指定する方法です。一時的に権限レベルを変更したいときに便利です。
承認ポリシーを指定するには、次のようにフラグを付けてCodexを起動します。
```
codex --sandbox workspace-write
```自動実行を利用する場合は、次のように指定できます。
```
codex --full-auto
```なお、CLIのオプション名や利用できる値はCodex CLIのバージョンによって異なる場合があります。 手元の環境で利用できるオプションは、codex –helpで確認してください。
設定ファイルでのデフォルト変更
毎回コマンドラインで設定するのが手間な場合は、Codexの設定ファイルでデフォルト値を変更する方法がおすすめです。
Codex CLIでは、ユーザー単位の設定を`~/.codex/config.toml`（または`~/.codex/config.yaml`）に配置します。次のように記述するとデフォルトの権限設定を変更できます。
```TOML
sandbox_mode = "workspace-write"
```設定ファイルで指定した値は、フラグなしでCodexを起動したときに自動で適用されます。CLIフラグで上書きすることも可能なため、柔軟に使い分けられます。
チームで共通の設定を使いたい場合は、プロジェクトルートに`.codex/config.json`を配置する方法もあります。グローバル設定よりプロジェクト設定が優先されるため、リポジトリごとの使い分けが可能です。
permissionプロファイルの指定
複数の権限設定を切り替えたい場合は、permissionプロファイル機能が役立ちます。
たとえば、「普段の開発用」と「安全性を優先する作業用」で設定を分けておけば、用途に応じて切り替えられます。
プロファイルの設定例は次のとおりです。
```TOML
[profiles.safe]
sandbox_mode = "read-only"
[profiles.dev]
sandbox_mode = "workspace-write"
```プロファイルを利用する場合は、現在利用しているCodex CLIの設定仕様を確認し、対応する方法で指定してください。この方法であれば「重要なプロジェクトでは制限を強める」「個人開発では必要な範囲だけ書き込みを許可する」といった使い分けがしやすくなります。
ただし、存在しない設定項目や古いバージョンの書式をそのままコピーしないことが大切です。Codex CLIはアップデートによって設定項目が変更される場合があるため、公式ドキュメントやcodex –helpで確認してから設定しましょう。
アプリ・IDE拡張での切り替え
CLIの操作に慣れていない場合は、CodexアプリやIDE拡張の設定画面から権限関連の設定を変更する方法もあります。
たとえばVSCodeでCodexを利用する場合は、拡張機能の設定やCodexのUIから、利用できる権限・承認関連の項目を確認できます。
基本的な流れは次のとおりです。
- VSCodeの拡張機能からCodexをインストールする
- Codexを起動する
- 権限や承認に関する設定項目を確認する
- 作業内容に合った設定を選択する
ただし、CLI・Codexアプリ・IDE拡張ですべての設定項目や表示方法が同じとは限りません。 また、設定の優先順位や利用できる機能はバージョンによって異なる場合があります。
そのため、VSCodeなどのIDEから利用する場合も、「GUIだから安全」と考えるのではなく、実際にどのファイルやコマンド、ネットワークへのアクセスが許可されているのかを確認することが重要です。
なお、VSCodeでCodexを利用する場合でも、permissionの考え方は同じです。「どこまでCodexに操作を任せるか」と「どの操作で確認を求めるか」を意識して設定しましょう。
CodexのIDEについて詳しく知りたい人は、次の記事を参考にしてください。
Codex permissionの使い方
Codex permissionを実際に活用する場面では、「毎回の承認を減らしたい」と「操作できる範囲を制限したい」という2つの観点が重要です。
ここからはCodex permissionの使い方を、2つにまとめて解説します。
毎回の許可承認を自動化する方法
毎回の許可確認をなくすには、承認ポリシーをon-requestやneverに変更する方法があります。
とくに、日常的な開発ではworkspace-writeとon-requestの組み合わせが使いやすい設定です。この場合、ワークスペース内で許可された操作はCodexが自律的に進め、サンドボックスの境界を越える必要がある操作では確認を求めます。
CLIでは、次のように指定できます。
```
codex --sandbox workspace-write --ask-for-approval on-request
```また、特定のコマンドだけ許可・確認・禁止したい場合は、Rulesを利用する方法があります。Rulesでは、コマンドのプレフィックスなどを指定し、そのコマンドを自動実行するか、ユーザーの確認を求めるか、実行を禁止するかを制御できます。設定ファイルのconfig.tomlでデフォルト値を指定することも可能です。
```TOML
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"
```neverを指定すると、承認プロンプトで処理を停止しなくなります。ただし、neverにしただけで操作範囲が無制限になるわけではありません。 サンドボックスの制限は別に適用されるため、workspace-writeと組み合わせれば、ワークスペース内の境界を維持したまま承認を省略できます。
一方、danger-full-accessとneverを組み合わせると、サンドボックスによる制限も解除されます。これはFull accessに相当する強い設定のため、安易に利用するのは避けましょう。
「許可がめんどくさい」という理由だけで制限をすべて解除するのではなく、まずはworkspace-write＋on-requestで承認回数を減らすところから始めるのがおすすめです。
Codexで自動承認する方法を詳しく知りたい人は、次の記事を参考にしてください。
許可範囲を制御する方法
Codexが操作できる範囲を細かく制御したい場合は、サンドボックスの設定、書き込み可能なディレクトリ、Rulesを組み合わせます。
たとえば、workspace-writeでは基本的に現在のワークスペース内でファイルを編集できます。さらに別のディレクトリへの書き込みが必要な場合は、サンドボックスを完全に解除するのではなく、writable_rootsで書き込み可能な場所を追加できます。
また、特定のコマンドだけ例外的に許可・確認・禁止したい場合は、Rulesを利用する方法があります。Rulesではコマンドのプレフィックス単位で、実行を許可するか、確認を求めるか、禁止するかを指定できます。
なお、AGENTS.mdとRulesは役割が異なります。 AGENTS.mdはCodexにプロジェクトの開発方針や作業上の注意事項を伝えるための指示ファイルであり、サンドボックスによる技術的なアクセス制御そのものではありません。一方、Rulesはコマンドの実行可否や確認を制御するための仕組みです。
そのため「.envは編集しない」「本番環境への操作は避ける」といった開発上のルールはAGENTS.mdに記載し、実際のコマンド実行範囲はサンドボックスやRulesで制御すると整理するとわかりやすいでしょう。
このように、Codexのpermissionでは「すべて自動化する」のではなく、サンドボックスで基本的な境界を設定し、必要な例外だけRulesなどで調整することが、安全性と利便性を両立するポイントです。
Codex permissionによく抱く疑問
Codex permissionを使い始めると、運用上の疑問がいくつか出てきます。ここからはよくある2つの疑問への回答をまとめます。
permissionモードは途中で変更できる？
Codexのpermissionやサンドボックス設定は、利用する環境やUIによって変更方法が異なります。
CLIで作業中にモードを切り替えたい場合は、Codexを一度終了して別のフラグ付きで再起動するのが基本です。
“`
# suggestモードで起動していた場合
# Ctrl+C で終了してから再起動
codex –approval-mode auto-edit
“`
特定のコマンドだけ許可・確認・禁止したい場合は、Rulesを利用する方法があります。Rulesでは、コマンドのプレフィックスなどを指定し、そのコマンドを自動実行するか、ユーザーの確認を求めるか、実行を禁止するかを制御できます。
VSCode拡張の場合は、設定画面からドロップダウンを変更するだけでリアルタイムに反映されます。再起動の必要はありません。
注意点として、モードを緩い方向（suggest → full-auto）に変更するときは、現在のプロジェクトの安全性を十分に確認してからにしましょう。厳しい方向（full-auto → suggest）への変更はいつでも安全に行えます。
たとえば、承認を減らしたい場合でも、danger-full-accessに変更する必要はありません。workspace-writeを維持したまま、承認ポリシーをon-requestやneverに変更することで、サンドボックスの境界を保ちながら自動化の度合いを高められます。
rulesが反映されないときは？
Rulesを設定したのに期待した動作にならない場合は、ファイルの場所やルールの内容、適用対象となるコマンドを確認しましょう。
とくに確認したいポイントは次のとおりです。
- Rulesファイルが正しい場所に配置されているか確認する
- ルールの構文やコマンドプレフィックスが正しいか確認する
- 実行しているコマンドがルールの対象になっているか確認する
- サンドボックスや承認ポリシーなど、別の設定が影響していないか確認する
設定を変更したら、まず単純なコマンドで期待した動作になるかを確認し、それでも反映されない場合は、Codex CLIのバージョンや公式ドキュメントに記載されている現在の設定方法を確認するのがおすすめです。
なお、Codexはアップデートによって設定項目や利用方法が変更される場合があるため、古い記事の設定例をそのまま使用しないよう注意しましょう。
Codexのルール機能について詳しく知りたい人は、次の記事を参考にしてください。
まとめ
本記事では、Codex permissionの仕組みと設定方法を解説しました。
Codex permissionでは、サンドボックスと承認ポリシーの2軸で、Codexが操作できる範囲とユーザーへの確認タイミングを設定できます。
まずはworkspace-write＋on-requestの組み合わせから始め、Codexの動作に慣れてきたら、必要な範囲で承認を減らしていくとよいでしょう。
すべての権限を一度に緩めるのではなく、サンドボックスで基本的な境界を設け、必要な操作だけを追加で許可することが、安全性と作業効率を両立するポイントです。
