Codex を毎日使うようになると、最初に困るのはモデル選びではありません。調査だけしたい日、通常の実装を任せたい日、PRレビューだけ走らせたい日、automation で人間が見ていない時間に動かしたい日で、必要な権限が違います。それなのに同じ config.toml で全部を動かすと、承認が多すぎるか、逆に広すぎる権限を常用するかのどちらかになります。
この記事では、Codex の config profile 設計 に絞って整理します。sandbox と approval の意味そのものは Codex sandbox / approvals 設計ガイド、auto-review の判断境界は Codex auto-review 設計ガイド、外部通信の許可は Codex internet access 安全運用ガイド、組織ルール全体は AIコーディングツールの社内ガイドライン に分けています。
今回の論点は、作業ごとに違う権限セットを profile として固定し、実行時に切り替えられるようにすることです。
先に結論: default config に全部入れない
私なら、~/.codex/config.toml は「普段の安全な既定値」だけにします。強い権限、長い reasoning、外部 network、MCP write tool、automation 用の非対話設定は、profile ファイルに逃がします。
# ~/.codex/config.toml
model = "gpt-5.6"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"これを土台に、作業別 profile を用意します。
# ~/.codex/review.config.toml
model_reasoning_effort = "high"
sandbox_mode = "read-only"
approval_policy = "never"# ~/.codex/implementation.config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"# ~/.codex/automation.config.toml
sandbox_mode = "workspace-write"
approval_policy = "never"起動時は次のように選びます。
codex --profile review
codex exec --profile automation "check the repo and report only new failures"OpenAI の docs では、profile は ~/.codex/<profile-name>.config.toml として分け、--profile profile-name で読み込む形になっています。古い [profiles.name] 形式を前提にすると現在の挙動とずれるため、新しく組むならファイル分割に寄せた方が安全です。
config の優先順位を先に決める
Codex の設定は1枚ではありません。ユーザー設定、profile、project config、CLI override が重なります。ここを知らずに profile を作ると、「review profile のはずなのに project config 側で network が開いていた」のような事故が起きます。
私なら、次の責務で分けます。
| 層 | 置くもの | 置かないもの |
|---|---|---|
| system config | 組織が絶対に禁止する値 | 個人の作業都合 |
~/.codex/config.toml | 普段の安全な既定値 | 強い権限、特殊 profile |
| profile file | 作業別の差分 | 全 profile 共通の長い設定 |
project .codex/config.toml | repo 固有の検証コマンド、MCP 接続の一部 | provider、通知、telemetry など machine-local な値 |
CLI --config | 1回だけの例外 | 継続運用する権限 |
実務では、project config に何でも入れない方がよいです。repo に入る設定はチームに配られます。provider、通知、telemetry、profile 選択のような機械ごとの設定は user config 側に残します。
profile は作業 lane で分ける
profile 名は、権限名ではなく作業 lane で付ける方が運用しやすいです。
| profile | 使う場面 | 権限の考え方 |
|---|---|---|
review | 差分レビュー、コード読解、設計確認 | read-only。編集しない |
implementation | 通常の修正、記事作成、テスト実行 | workspace-write + on-request |
security-review | 依存、権限、外部接続の確認 | read-heavy。必要時だけ承認 |
automation | 定期実行、夜間監視、CI補助 | 非対話だが workspace を狭くする |
mcp-admin | MCP 設定や外部 tool の棚卸し | write tool は人間承認へ戻す |
danger-full-access を profile として作る場合でも、名前は full-access ではなく local-maintenance のように用途を狭くした方がよいです。権限名を profile 名にすると、「強いから便利」という理由で普段使いされやすくなります。
sandbox と approval を profile に混ぜすぎない
sandbox_mode は何ができるか、approval_policy はいつ止まるかを決めます。この2つは近いですが、同じものではありません。
たとえば approval_policy = "never" は、承認プロンプトを出さない設定です。これだけで安全になるわけではありません。automation で never を使うなら、sandbox や permissions profile 側で動ける範囲を先に狭めます。
# ~/.codex/readonly-report.config.toml
sandbox_mode = "read-only"
approval_policy = "never"この profile は、差分調査やレポート作成には向いています。逆に、修正まで任せたい automation で workspace-write + never を使うなら、対象 worktree、branch、write 可能な directory、network なし、PR 作成前の build gate までセットで固定します。
permissions profile へ移すタイミング
OpenAI docs では、beta の permissions profile も提供されています。これは filesystem と network の policy を named profile として扱う仕組みです。ただし、旧来の sandbox_mode / sandbox_workspace_write とそのまま混ぜて使うものではありません。
最初から permissions profile へ飛ぶ必要はありません。私なら次の順で進めます。
- まず
workspace-write + on-requestで通常運用する - 何が頻繁に承認待ちになるかをログから見る
- safe な反復操作だけ rules や permissions profile に寄せる
- network と filesystem を同じ profile で説明できる段階で移行する
permissions profile を使うなら、目的は「承認を消すこと」ではなく、許可範囲を説明できる名前にすることです。
default_permissions = "project-edit"
approval_policy = "on-request"
[permissions.project-edit]
description = "Edit the active project and run local validation without network access."
[permissions.project-edit.filesystem]
":minimal" = "read"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"この例では、Codex は workspace 内の編集に集中できます。.env は読ませず、network もこの profile では開きません。外部 docs を読ませたいなら、この profile を広げるのではなく、別の docs-research profile を作る方が監査しやすいです。
MCP は profile と同じ単位で許可しない
MCP server は便利ですが、profile と同じ粒度で雑に開くと危険です。implementation profile で read-only docs MCP を使うのは自然ですが、同じ profile に GitHub write、Calendar write、database write まで入れると、作業 lane の意味が崩れます。
私なら、MCP は次の3分類で profile に対応させます。
| MCP 種別 | 例 | profile 方針 |
|---|---|---|
| read-only reference | docs、schema、search | review / implementation で許可しやすい |
| inspect with auth | issue、logs、metrics | security-review か専用 profile |
| write / external action | PR comment、calendar、ticket更新 | mcp-admin で人間承認へ戻す |
MCP の台帳化は MCP サーバーカタログ設計ガイド、未信頼入力の扱いは MCP prompt injection 対策ガイド に分けています。config profile 側でやるべきことは、どの lane でどの MCP を読み込むかを曖昧にしないことです。
project config は便利だが、信用しすぎない
.codex/config.toml を repo に置くと、チーム全体で標準の挙動を揃えられます。たとえば、この repo では build command、format command、docs MCP の接続、project-local rules を固定したい場面があります。
ただし、project config は「この repo での作業をしやすくする層」です。個人の secret、広い network、machine-local path、通知、provider 設定まで入れる場所ではありません。
私なら project config に置くのは次の程度にします。
# .codex/config.toml
approval_policy = "on-request"
[mcp_servers.docs]
enabled = trueそして、dangerous な設定は user profile 側で明示的に選ばせます。repo を clone しただけで強い権限が有効になる構成は避けます。
運用で見るべき checklist
config profile を作ったら、最後に次の観点で見ます。
- default config だけで daily work が安全に始まるか
reviewprofile が本当に編集できないかautomationprofile が非対話でも workspace 外へ出られないかdanger-full-accessが常用名になっていないか- project config に machine-local な値を入れていないか
- MCP write tool が通常 profile に混ざっていないか
- profile ごとの想定作業を AGENTS.md か社内ガイドラインに書いているか
特に大事なのは 3 です。人間が見ていない時間に動く profile は、approval prompt を出せないことがあります。だからこそ、approval ではなく sandbox / permissions / worktree / branch protection で先に事故半径を絞ります。
まとめ
Codex config profile は、便利設定の寄せ集めではありません。作業の種類ごとに、どこまで読めるか、どこを書けるか、いつ止まるか、どの MCP を使えるかを固定する運用設計です。
最初は ~/.codex/config.toml を薄く保ち、review、implementation、automation の3つだけで十分です。そこから approval 待ちや network 需要を見て、permissions profile や MCP 専用 profile に分けます。
Codex を安全に速く使うには、毎回その場で許可を考えるより、作業前に profile を選ぶ方が安定します。profile は権限のショートカットではなく、作業 lane の境界として設計するのがよいです。