Codex CLI 0.128.0 で --full-auto が deprecated になり Permission Profile への移行が推奨されるようになった

Codex CLI 0.128.0 で --full-auto が deprecated になり Permission Profile への移行が推奨されるようになった

2026.05.12

どうも!オペ部の西村祐二です!

OpenAI Codex CLIrust-v0.128.0 が2026-04-30にリリースされ、--full-auto フラグが deprecated になりました。TUI (codex) では既にエラーになるところまで進んでおり、codex exec のみ警告付きで残っています。あわせて Permission Profile への移行も進んでいたので、現時点の状態を整理してみます。

何がリリースされたか

  • 概要: PR #20133--full-auto の deprecation がはじまりました。TUI と codex sandbox ではパース自体が失敗するように変更され、codex exec のみ警告を出しつつ受け付ける状態です。あわせて PR #19900 / PR #20117 / PR #20118 / PR #20095 で Permission Profile が built-in 名 (:read-only / :workspace / :danger-no-sandbox) を持つ形に整理され、CLI からも明示的に指定できるようになっています。
  • 公式リンク: openai/codex rust-v0.128.0

ポイント

  1. --full-auto の段階的廃止

    • TUI と codex sandbox <os> では --full-auto がオプションとして残っておらず、付けて起動すると error: unexpected argument '--full-auto' found で失敗します。
    • codex exec だけは hidden flag として受け付けつつ warning: `--full-auto` is deprecated; use `--sandbox workspace-write` instead. を出力する状態で、リリースノートにも「今後のリリースで完全削除予定」と書かれています。
  2. Built-in permission profile の整備

    • :read-only / :workspace / :danger-no-sandbox の3種類が組み込み profile として用意されました。先頭の : は built-in の名前空間として予約されています。
    • config.tomldefault_permissions = ":workspace" のように指定するだけで、[permissions] テーブルを書かずに切り替えられます。
    • 空 config の既定は次の通りです。trusted / untrusted project は :workspace(非 Windows、もしくは Windows sandbox 有効時)。それ以外は :read-only
  3. codex sandbox--permissions-profile が追加

    • codex sandbox macos|linux|windows --permissions-profile :workspace -- <cmd> のように、サンドボックスのテストや単発実行で使う profile を CLI から直接指定できるようになりました。--permissions-profile を指定したときに限り、-C/--cd でカレントディレクトリも指定できます。

試してみる

環境

  • Codex CLI 0.130.0
  • macOS (Apple Silicon)

1. --full-auto の挙動を確認する

codex (TUI) では --full-auto がオプションとして残っていないため、付けて起動するとパースエラーになります。

$ codex --full-auto
error: unexpected argument '--full-auto' found

  tip: to pass '--full-auto' as a value, use '-- --full-auto'

Usage: codex [OPTIONS] [PROMPT]
       codex [OPTIONS] <COMMAND> [ARGS]

For more information, try '--help'.

codex exec は警告付きで受け付ける状態です。

$ codex exec --full-auto
warning: `--full-auto` is deprecated; use `--sandbox workspace-write` instead.
Reading prompt from stdin...

2. --sandbox workspace-write で置き換える

公式の置き換え先は --sandbox workspace-write です。--full-auto は内部的に SandboxMode::WorkspaceWriteAskForApproval::OnRequest をまとめて設定していました。承認モードを揃えるなら -a on-request の併用が従来挙動に近くなります。

# 0.127 以前と同じ挙動を再現する場合
$ codex exec --sandbox workspace-write -a on-request 'fix the failing tests'

--sandbox には read-only / workspace-write / danger-full-access の3つが指定でき、codex --help のヘルプにも同じ値が並んでいます。

3. config.toml で built-in profile を使う

毎回 CLI で書くのが面倒な場合は、~/.codex/config.tomldefault_permissions を指定します。built-in profile を使うなら : プレフィックスを付けます。

~/.codex/config.toml
default_permissions = ":workspace"

[permissions] テーブルを書く必要はありません。built-in 名は3種類で、旧来の指定との対応を表にすると次のようになります。

Before (旧来の指定) After (built-in profile) sandbox mode 用途
--sandbox read-only default_permissions = ":read-only" read-only 読み取りのみ。ファイル変更もシェル実行もしない
--full-auto または --sandbox workspace-write + -a on-request default_permissions = ":workspace" workspace-write ワークスペース配下に書き込みを許可、必要時のみ承認
--sandbox danger-full-access default_permissions = ":danger-no-sandbox" danger-full-access サンドボックス無効。/trust 済みの信頼できる環境向け

: 始まりで未知の名前を指定すると、default_permissions refers to unknown built-in profile というエラーで起動が失敗するようになっていました。なお --sandbox CLI フラグ自体は legacy として依然動作するため、CI スクリプトなど CLI 直書きの構成は段階的に置き換えていけば問題なさそうです。

4. ユーザー定義の profile を作る

ネットワークやファイルシステムだけ調整したい場合は、: を付けない名前でユーザー定義の profile を書きます。[permissions.<name>] テーブルが必須です。

~/.codex/config.toml
default_permissions = "my-workspace"

[permissions.my-workspace.filesystem]
":minimal" = "read"

[permissions.my-workspace.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"

ここで default_permissions = "my-workspace"コロン無し は重要で、built-in 名 ":workspace" と区別する仕組みになっています。

  • default_permissions = ":workspace" → 組み込みの :workspace profile を使う([permissions.*] テーブルは不要)
  • default_permissions = "my-workspace" → 同名の [permissions.my-workspace] テーブルで自前定義した profile を使う

組み込みと同じ名前(例: "workspace")をユーザー定義に再利用しても動きますが、見分けが付きにくくなるため、上の例のように別名にしておくと安全です。

設定キーの読み方は次の通りです。

  • 左辺 ":minimal" は Codex 内部で定義された 特殊パス名 (FileSystemSpecialPath) の一つで、サンドボックスが最低限動作するために必要なシステムパス群(言語ランタイムやシステムライブラリ等)を指します。他にも ":root"":project-roots"(エイリアス ":current_working_directory")、":tmpdir"":slash-tmp" があり、絶対パス(例: "/Users/me/projects")を直接書くこともできます。
  • 右辺の "read"FileSystemAccessMode の値で、"read" / "write" / "none" の3つから選びます。"none" は明示的な拒否、"write" は読み書き許可です。

つまりこの例は「:minimal パス群には read のみ許可、ネットワークは有効化してプロキシ経由」という profile を my-workspace という名前で定義したことになります。

5. codex sandbox に profile を渡してテストする

codex sandbox でも --permissions-profile で profile を指定できるようになりました。手元のコマンドが想定どおりのサンドボックス境界で動くか試すのに使えそうです。

$ codex sandbox macos --permissions-profile :workspace -- echo "hello from sandbox"
$ codex sandbox macos --permissions-profile :read-only -C /tmp/project -- ls

6. アクティブな profile を確認する

PR #20095ActivePermissionProfile { id, extends, modifications } のメタデータが app-server や TUI に流れるようになっています。TUI で /status を開くと、built-in の場合は Workspace / Read Only / No Sandbox / Full Access、ユーザー定義の場合は Profile <id> の表記で現在のプロファイルが表示されました。

試してみた感想

--full-auto は workspace-write と on-request approval を1つにまとめた便利なフラグでした。これに慣れているとフラグを分けて書くひと手間が増えた印象です。とはいえ ~/.codex/config.tomldefault_permissions = ":workspace" と書いておけば、CLI 側でフラグを並べる必要はなくなります。profile という抽象を介して意図が伝わるようになる分、永続設定との相性は良いと感じました。

私自身は Claude Code から Codex を呼び出す構成で codex exec --full-auto ... を使っており、今回の deprecation の影響を受けた立場です。~/.codex/config.tomldefault_permissions = ":workspace" を追加して対応しました。呼び出し側からは --full-auto を外すだけで済むため、コマンド文字列が長くならずに済んでいます。Claude Code から codex exec を叩くような外部呼び出し型の運用では、警告ログが積み重なる前に config 側へ寄せてしまうのが楽そうです。

まとめ

Codex CLI 0.128.0 で --full-auto の deprecation が始まり、TUI ではパース不可、codex exec では警告付きという状態になりました。今後のリリースで完全削除される予定があるため、ローカルやプロジェクトの設定にハードコードしている場合は、--sandbox workspace-writedefault_permissions = ":workspace" への置き換えを進めておくと良さそうです。

誰かの参考になれば幸いです。


関連リンク:


生成AI活用はクラスメソッドにお任せ

過去に支援してきた生成AIの支援実績100+を元にホワイトペーパーを作成しました。御社が抱えている課題のうち、どれが解決できて、どのようなサービスが受けられるのか?4つのフェーズに分けてまとめています。どうぞお気軽にご覧ください。

生成AI資料イメージ

無料でダウンロードする

この記事をシェアする

関連記事