Codexのuntrusted承認ポリシー廃止：何を変更すべきか

Codex CLI v0.149.0（安定版、2026年8月20日）は、PR #39630「Retire the untrusted approval policy」（untrusted承認ポリシーの廃止）でuntrusted承認ポリシーを廃止しました。¹ このPRはuntrustedを「from the CLI, configuration schema, and MCP tool interface」（CLI、設定スキーマ、MCPツールインターフェースから）削除し、明示的なapproval_policy = "untrusted"は「with an actionable error」（対処可能なエラーを伴って）失敗するようになりました。⁴ 2026年8月25日に0.149.1で再現したところ、値がconfig.tomlにあってもプロファイルファイルにあっても-cオーバーライドにあっても、セッションの起動はError: approval_policy = "untrusted" is no longer supported; remove this settingで止まり、codexバイナリは引数の解析段階で-a untrustedを拒否します。⁵ 値をon-requestに変更し、サンドボックスモードはそのままにしてください。もっとも慎重な構成にするなら、--sandbox read-onlyとon-requestを組み合わせます。³ 現在のポリシーの選択肢はon-request、never、そして詳細指定（granular）のテーブル形式の3つです。² 内容はnpmのlatestであるv0.149.1（2026年8月24日、UTC）時点のものです。¹ {.answer-block}

TL;DR

• 変更点： v0.149.0の完全な変更履歴にはPR #39630「Retire the untrusted approval policy」が載っています。リリースノートにはそのタイトル以上の移行に関する記述はありません。¹ PRの説明にはあります。untrustedはCLI、設定スキーマ、MCPツールインターフェースから消え、明示的な設定は「now fail with an actionable error」（対処可能なエラーで失敗するようになった）とのことです。⁴
• 対応が必要な人： ~/.codex/config.tomlまたはプロファイルにapproval_policy = "untrusted"がある人、そしてスクリプト、エイリアス、CIで--ask-for-approval untrusted（または-a untrusted）を渡している人すべてです。
• 置き換え先： on-requestです。サンドボックスモードは変更しません。read-onlyとon-requestの組み合わせが、ドキュメントで「Safe read-only browsing」（安全な読み取り専用ブラウジング）とされているペアです。² 以前のworkspace-writeとuntrustedの組み合わせには直接の後継がなく、コマンド単位のプロンプトは今ではexecポリシールールの担当です。⁴⁸
• 現在の選択肢： on-request、never、またはカテゴリ単位で制御するapproval_policy = { granular = { ... } }です。サンドボックスモードはread-only、workspace-write、danger-full-accessのままです。²
• 静かに壊れるのではなく、即座に失敗します： 残ったapproval_policy = "untrusted"は、config.tomlでもプロファイルファイルでも-cオーバーライドでも、Error: approval_policy = "untrusted" is no longer supported; remove this settingでセッションを止めます。codex doctorは設定を読み込めなかったと報告するだけで、キー名は示しません。⁵

Codex 0.149は何を変えたのですか？

目玉はcodex agentsダッシュボード、codex queue、拡張されたcodex doctorといった新しい機能面で、承認まわりの変更はそれより下、完全な変更履歴の中にあります。¹ リリースノートが省いている詳細は、PR #39630の説明にあります。3つの箇条書きのうち2つがここで重要です。「Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error.」（untrustedをCLI、設定スキーマ、MCPツールインターフェースから削除する。明示的なapproval_policy = "untrusted"設定は対処可能なエラーで失敗するようになる）と、「Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.」（既知の安全なコマンドの許可リストを削除する。untrustedとマークされたプロジェクトは、明示的なexecポリシールールが許可しない限り、すべてのコマンドで承認を求めるようになる）です。⁴ 同じリリースに含まれるバグ修正の1つも、同じ読者にとって重要です。「Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.」（再開およびフォークしたスレッドは、黙って現在のデフォルトにフォールバックするのではなく、アクティブな権限プロファイルを復元するようになった）。¹

各行はv0.149.0のリリースノートからの引用です。¹

誰が何を編集する必要がありますか？

この値が置かれる場所は4つあります。まずそのすべてを見つけてください。メインファイルを直しても、プロファイルやシェルのエイリアスが古いポリシーを再び有効にしてしまうからです。

レガシーテーブルの失敗は目立ちます。0.149.1では、config.tomlに[profiles.safe]テーブルが残ったままcodex exec --profile safe "hi"を実行すると、Error loading config.toml: --profile `safe` cannot be used while .../config.toml contains legacy `profile = "safe"` or `[profiles.safe]` config; move those settings into .../safe.config.toml ...で止まります。つまり、チームメイトの--profile safeは、Codexが承認の値を読む前に失敗するのです。⁵

設定側とスクリプト側にgrepを1つずつ：

# Config and profiles: match the key, not the bare word
grep -rnE 'approval_policy\s*=\s*"untrusted"' ~/.codex/*.toml .codex/config.toml 2>/dev/null

# Scripts, aliases, CI
grep -rn --exclude-dir=node_modules \
  -e "ask-for-approval untrusted" -e "ask-for-approval=untrusted" \
  -e "-a untrusted" -e "approval_policy=untrusted" \
  ~/.zshrc ~/.bashrc . 2>/dev/null

# CI directories: read every bare hit, because YAML can split a flag from its value
grep -rn --exclude-dir=node_modules "untrusted" .github .gitlab-ci.yml .circleci 2>/dev/null

最初のgrepが素の単語ではなくキーに一致させているのには理由があります。trust_level = "untrusted"は別の設定なので、そのままにしてください。設定リファレンスはprojects.<path>.trust_levelを、「a project or worktree as trusted or untrusted」（プロジェクトまたはワークツリーを信頼済みか未信頼か）としてマークするキーと定義しており、未信頼のプロジェクトは「skip project-scoped .codex/ layers, including project-local config, hooks, and rules」（プロジェクトローカルの設定、フック、ルールを含む、プロジェクトスコープの.codex/レイヤーをスキップする）とされています。⁷ PR #39630が変えるのは、未信頼のプロジェクトがコマンドをどう扱うかであって、このキーではありません。「Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.」⁴ untrustedを盲目的に一括置換すると、このキーを壊してしまいます。

プロファイルファイルはドキュメント化されたプリセットの仕組み（~/.codex/<name>.config.toml、codex --profile <name>で選択）なので、メイン設定がどうなっていようと、チームメイトのプロファイルが廃止された値を持ち込み直すことがあります。²

現在の承認ポリシーの選択肢は何ですか？

Codexのセキュリティは2つの層から成ります。サンドボックスモードがCodexに技術的に何ができるかを決め、承認ポリシーがCodexがいつ立ち止まって確認すべきかを決めます。² 今回の廃止が触れるのは2つ目だけです。

granular形式は5つのプロンプトカテゴリを扱います。sandbox_approval、rules（execpolicyのプロンプト）、mcp_elicitations、request_permissions、skill_approvalです。² このどれもuntrustedを再現しません。untrustedはプロンプトカテゴリのフィルタではなく、コマンド分類のルール（既知の安全な読み取りは自動実行し、状態を変更しうるものはすべて確認する）だったからです。²

workspace-writeとuntrustedの組み合わせ、つまりドキュメントで「Automatically edit but ask for approval to run untrusted commands」（自動的に編集するが、untrustedなコマンドの実行には承認を求める）とされている行には、直接の後継がありません。² workspace-writeとon-requestはサンドボックス内で実行されるコマンドについて確認しなくなり、read-onlyとon-requestはコマンドだけでなく編集についても確認します。² PR #39630は「the known-safe command allowlist」（既知の安全なコマンドの許可リスト）を削除し、コマンド単位のプロンプトのために残る仕組みを名指ししています。「Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.」⁴ execポリシールールは、granularテーブルのrulesカテゴリ、つまり承認ページが挙げる「execpolicy-rule prompts」の背後にあるのと同じ仕組みです。² 書き込み可能なワークスペースでuntrustedに頼っていたセキュリティ担当者は、このルールを整備すべきです。ルールのドキュメントはその適用範囲をサンドボックスの外で実行されるコマンドに限定しており、decision = "prompt"を持つprefix_ruleは「before each matching invocation」（一致する呼び出しのたびにその前で）確認します。⁸

# ~/.codex/rules/default.rules
prefix_rule(pattern = ["git", "push"], decision = "prompt")

読み取り専用サンドボックスは、変更を丸ごとブロックする素朴な代替手段として残っています。³

具体的な編集内容は何ですか？

対応表は1行です。untrustedをon-requestにし、サンドボックスモードは今のままにします。³

メイン設定（プロファイルファイルもまったく同じ編集です）：

# ~/.codex/config.toml (before)
approval_policy = "untrusted"
sandbox_mode    = "read-only"

# ~/.codex/config.toml (after)
approval_policy = "on-request"
sandbox_mode    = "read-only"

スクリプト：

# before
codex --sandbox workspace-write --ask-for-approval untrusted "$@"

# after
codex --sandbox workspace-write --ask-for-approval on-request "$@"

-a/--ask-for-approvalのペアはcodex TUIバイナリのものです。codex execにはこのフラグがなく、0.149.1ではcodex exec --ask-for-approval untrusted "hi"がerror: unexpected argument '--ask-for-approval' foundで失敗します。⁵ codex execでは、ポリシーを設定ファイルに書くか、インラインで渡します。

# non-interactive run, policy set inline
codex exec --sandbox workspace-write -c approval_policy=never "$@"

判断が必要な点が2つ続きます。第一に、誰もプロンプトに答えられない場所では、on-request下の対話型codexバイナリは最初の承認で止まってしまいます。ドキュメント化された非対話型のペアは--sandbox read-only --ask-for-approval neverで、codex exec --sandbox workspace-writeがドキュメント化された非対話型の入口です。² 第二に、「フルパワーだが毎回確認する」ためにuntrustedとdanger-full-accessを組み合わせていた場合、その性質は置き換え後には残りません。ドキュメントが挙げるon-requestのプロンプトの例はサンドボックスの外へ出ることとネットワークを使うことの2つで、danger-full-accessはその両方のトリガーを取り除きます。² granularテーブルの他の4カテゴリからのプロンプト、すなわちdecision = "prompt"を持つexecポリシールール、MCPのelicitation、スキルの承認、request_permissionsのプロンプトは、フルアクセス下でも引き続き発火します。²⁸ 任意のapprovals_reviewer = "auto_review"設定は、対象となるプロンプトをレビュアーエージェントに回します。これは対話型ポリシーにのみ適用されるため、移行後も引き続き利用できます。²

変更が反映されたことをどう確認しますか？

1. codex doctorを実行します。廃止された値が設定に残っていると、そのconfig行は✗ config config could not be loadedで始まり、詳細行は· failed to load Codex configとなります。doctorは問題のキーを名指ししません。名前入りのエラーはcodexまたはcodex execの起動時に出ます。doctorの行がクリーンなら値は消えています。失敗しているなら、どのキーかを見るためにセッションを起動する必要があります。⁵ 起動時のエラーは、値がconfig.tomlにあっても、--profileで選んだプロファイルファイルにあっても、-c approval_policy=untrustedオーバーライドにあっても同一です。⁵ フラグ形式はもっと早く、引数の解析段階で失敗します。codex -a untrusted --versionはerror: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'に続けて[possible values: on-request, never]を出力します。⁵
2. 作業用ディレクトリで使い捨てのセッションを開始し、/statusを実行します。そのPermissions行がアクティブなポリシーを示し、on-requestはそこで「Ask for approval」と表示されます。⁵ /permissionsはアクティブなモードを報告するのではなくプリセットメニューを開くので、代わりに/statusを読んでください。⁵ /statusはワークスペースのディレクトリも一覧します。²
3. 古いスレッドを1つ再開します。PR #39153「Restore permission profiles when resuming threads」（スレッド再開時に権限プロファイルを復元）により、今では「the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread」（スレッドの再開またはフォーク時に、最後に永続化された承認ポリシー、承認レビュアー、アクティブな権限プロファイルID）が復元されます。⁶ 永続化されたポリシーがuntrustedである再開スレッドについては未検証です。実際に開くまでは、不明なケースとして扱ってください。

ドキュメント自体について1つ注意があります。公式の「Agent approvals & security」ページは、2026年8月24日に取得して8月25日に再確認した時点でも、組み合わせの表に--ask-for-approval untrustedを載せたままで、「With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically」（--ask-for-approval untrustedでは、Codexは既知の安全な読み取り操作のみを自動実行する）で始まる段落も残っており、config.tomlの例でもapproval_policy = "untrusted"を使っています。² 設定リファレンスのapproval_policy項目は型の共用体でuntrustedを先頭に挙げながら、説明では別の値を廃止済みとしています。「on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs.」（on-failureは非推奨。対話型の実行にはon-requestを、非対話型の実行にはneverを使う）。⁷ 権威ある記録はPRとバイナリであり、ドキュメントはそれに遅れています。ドキュメントの例ブロックを、値を差し替えずに新規の0.149環境へコピーしないでください。

FAQ

Codexでapproval_policy = "untrusted"の代わりになるものは何ですか？

approval_policy = "on-request"です。既存のsandbox_modeは変更しません。もっとも慎重な組み合わせにするなら、あわせてsandbox_mode = "read-only"を設定します。³

untrustedポリシーを廃止したのはCodexのどのバージョンですか？

2026年8月20日に安定版となったv0.149.0で、完全な変更履歴のPR #39630によるものです。v0.149.1（2026年8月24日、UTC）が現在のnpmのlatestです。¹

config.tomlにuntrustedを残したままだとどうなりますか？

Codexはセッションの開始を拒否します。0.149.1では、codex execがError: approval_policy = "untrusted" is no longer supported; remove this settingで止まり、プロファイルファイルでも-c approval_policy=untrustedでも同じエラーが出て、codex doctorは設定を読み込めなかったと報告するだけです。⁵ PR #39630はこの挙動を「with an actionable error」（対処可能なエラーを伴って）失敗すると説明しています。⁴

on-requestはuntrustedより安全性が低いのですか？

workspace-writeの中では、そのとおりです。untrustedは状態を変更しうるすべてのコマンドの前に確認していましたが、on-requestはサンドボックス内のコマンドを確認なしに実行します。² サンドボックス層がその差を部分的に埋めます。read-onlyはポリシーに関係なく書き込みをブロックし、on-requestはあらゆる権限昇格の前に引き続き確認します。³ 書き込み可能なワークスペースでコマンド単位の確認が必要なら、PR #39630が名指ししている仕組みであるexecポリシールールを書いてください。⁴⁸

サンドボックスモードも変更する必要がありますか？

いいえ。今回の廃止が影響するのは承認ポリシーだけです。read-only、workspace-write、danger-full-accessは今のままにしてください。³

重要なポイント

個々の開発者向け： - ~/.codex/*.tomlを（素の単語ではなく）approval_policy = "untrusted"でgrepし、一致した箇所をそれぞれon-requestに置き換え、sandbox_modeとtrust_level = "untrusted"には手を触れないでください。 - codex doctorを実行し、次に使い捨てセッションで/statusを確認し、古いスレッドを1つ再開して0.149が何を復元するか見てください。

共有プロファイルとスクリプトを管理するチーム向け： - プロファイルファイルとインラインのオーバーライドは、config.tomlと同じコミットで修正します。レガシーな[profiles.<name>]テーブルは、~/.codex/<name>.config.tomlへ移すまで--profileを完全にブロックします。⁵ - 無人のジョブは、codexバイナリなら--sandbox read-only --ask-for-approval neverに、またはcodex exec --sandbox workspace-write -c approval_policy=neverに切り替えます。on-request下の対話型codexバイナリは誰も答えないプロンプトで止まり、codex execには--ask-for-approvalフラグがありません。⁵

セキュリティ担当者向け： - untrustedの分類器（安全な読み取りは自動実行し、変更時に確認する）にはgranularでの同等物がありません。PR #39630はコマンド単位の確認についてexecポリシールール（「unless an explicit exec policy rule allows it」）を指しており、⁴ これは~/.codex/rules/default.rulesにdecision = "prompt"を持つprefix_ruleとして書きます。⁸ そして読み取り専用サンドボックスは変更を丸ごとブロックします。 - レビュアーエージェントが対象となるプロンプトで人間の代わりを務められる場面では、approvals_reviewer = "auto_review"を検討してください。

参考文献