Claude Codeの --dangerously-skip-permissions に近い使い方を Codex CLI で試したところ、起動引数ではうまくいかず、config.toml に設定を書く方法が確実でした。
最初にわかったこと
codex --full-auto は unexpected argument '--full-auto' found になりました。
codex --approval-policy never も同じく引数として認識されませんでした。
対話中の /mode や /approvals も、今回の環境では使えませんでした。
結論
Codex CLI では、承認なしで動かしたい場合は config.toml に設定を書くのが基本です。
Windows では %UserProfile%\.codex\config.toml を編集します。
設定例
approval_policy = "never"
sandbox_mode = "danger-full-access"
model = "gpt-5.5"
model_reasoning_effort = "medium"
[projects.'c:\users\user']
trust_level = "trusted"
[projects.'c:\users\user\downloads\local-agent-codex-handoff-v2']
trust_level = "trusted"
[projects.'c:\users\user\ai-info-search-engine']
trust_level = "trusted"
[tui.model_availability_nux]
"gpt-5.5" = 4
[windows]
sandbox = "elevated"この設定の意味
approval_policy = "never" は、承認プロンプトを出さない設定です。
sandbox_mode = "danger-full-access" は、サンドボックス制限を外して強い権限で動かす設定です。
設定を保存したら、Codex を再起動して使います。
なぜ引数でうまくいかなかったのか
今回のエラーは、使っている Codex CLI がその引数をサポートしていないために起きています。
Codex の公式ドキュメントでも、承認ポリシーやサンドボックス制御は config で扱う前提が案内されています。
安全に使うための考え方
承認なしで動かすのは便利ですが、危険な操作もそのまま実行される可能性があります。
そのため、まずは信頼できるプロジェクトだけを対象にして、必要最小限の権限で試すのが安全です。
また、実運用ではローカルの検証用環境やVM、コンテナなど隔離された環境で使うとリスクを下げられます。
Claude Codeとの違い
Claude Codeの --dangerously-skip-permissions は、起動時フラグで承認を飛ばす考え方です。
一方で Codex CLI は、今回の検証では config.toml による設定が中心でした。
つまり、見た目は似ていても、実際の操作方法は同じではありません。
まとめ
Codex CLI を承認なしで動かしたい場合は、起動引数を探すより config.toml を設定するのが確実です。
基本は approval_policy = "never" と sandbox_mode = "danger-full-access" の組み合わせです。
ただし、強い権限を使うので、信頼できる環境でのみ運用するのが前提です。
