0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

Codex CLI 0.149.1、untrustedの承認ポリシーが本当に消えていた

0
Posted at

はじめに

Codex CLI を業務の CI に組み込んでいると、「マイナーバージョンを1つ上げただけなのに、指定していたオプション値が急にエラーになった」という経験をすることがあります。今回は @openai/codex を 0.148.0 から 0.149.1 に上げる過程で、実際にその事象に遭遇しました。単なるヘルプ文言の変更なのか、それとも本当に機能が削除されたのか、両バージョンを並べてインストールして確かめています。

この記事で学べること

  • Codex CLI 0.148.0 → 0.149.1 で実際に何が変わったか（--help の diff と実行結果から確認した事実のみ）
  • --ask-for-approval untrusted が本当に無効な値になっていることの実機確認
  • 新しく追加された codex agents / codex queue サブコマンドの実際の挙動（認証なし環境での結果込み）

対象読者

Codex CLI を CI パイプラインやローカル環境で運用しており、バージョンアップ時の破壊的変更を事前に把握したいエンジニア向けです。

前提環境

  • OS: Ubuntu 24.04.4 LTS（クラウド実行環境・/etc/os-release の VERSION より）
  • Node.js: v22.22.2 / npm: 10.9.7
  • 検証パッケージ: @openai/codex（npm 公式レジストリ）

TL;DR

  • @openai/codex は 0.148.0（npm 公開: 2026-08-18T22:30 UTC）から 0.149.1（npm 公開: 2026-08-24T00:32 UTC）の間に、--ask-for-approval untrusted が実際にエラーを返す無効値になっていた（ヘルプ文言が消えただけではない）
  • 新規サブコマンド codex agents（セッション一覧のTUI）と codex queue --thread <ID> --message <TEXT>（既存セッションへのメッセージ投入）が追加されていた
  • codex doctor と codex features list は認証なしでも実行でき、インストール診断とフィーチャーフラグの状態を確認できる

背景・課題

Codex CLI の変更履歴は GitHub の CHANGELOG や Releasebot 経由のまとめ記事で追えますが、「ヘルプの表示が変わった」という記述だけでは、それが単なる説明文の整理なのか、実際に値を渡すとエラーになる破壊的変更なのかを文章から判断するのは困難です。特に --ask-for-approval はCI設定やスクリプトに直接値を渡すオプションのため、意味が変わっていないか実際に動かして確かめる必要がありました。

やったこと

新旧2バージョンを別ディレクトリにインストールし、同じコマンドを両方で実行して差分を取りました。

ステップ1: 新旧バージョンを並べてインストール

グローバルに最新版、別ディレクトリにローカルインストールで旧版を入れることで、1台の環境上で両バージョンを共存させました。

npm install -g @openai/codex@0.149.1
mkdir -p /tmp/codex-old && cd /tmp/codex-old
npm install @openai/codex@0.148.0

実行後、それぞれのバイナリでバージョンを確認します。

$ codex --version
codex-cli 0.149.1

$ /tmp/codex-old/node_modules/.bin/codex --version
codex-cli 0.148.0

ステップ2: --help の差分を取る

diff <(/tmp/codex-old/node_modules/.bin/codex --help 2>&1) <(codex --help 2>&1)

実際の出力は次の3点でした。

8a9
>   agents            Browse all agent sessions on the shared local app-server daemon
26a28
>   queue             Queue a message for an existing session
112,114d113
<           - untrusted:  Only run "trusted" commands (e.g. ls, cat, sed) without asking for user
<             approval. Will escalate to the user if the model proposes a command that is not in the
<             "trusted" set

サブコマンド一覧に agents と queue が増え、--ask-for-approval の説明文から untrusted の項目がまるごと消えています。ここまではヘルプの見た目の変化ですが、値として本当に使えなくなったのかは別途確認が必要です。

ステップ3: untrusted が実際にエラーになるか実行して確かめる

0.149.1 で untrusted を指定してみると、次のように弾かれました。

$ codex --ask-for-approval untrusted --help
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
  [possible values: on-request, never]

For more information, try '--help'.

同じコマンドを 0.148.0 で実行すると、エラーにならずヘルプが表示されました。

$ /tmp/codex-old/node_modules/.bin/codex --ask-for-approval untrusted --help
Codex CLI

If no subcommand is specified, options will be forwarded to the interactive CLI.
...(略・正常にヘルプが表示される)

これで untrusted はヘルプの説明が消えただけでなく、clap の値バリデーションレベルで受け付けなくなっている ことが確認できました。今回実機比較したのは 0.148.0 と 0.149.1 の2点なので、途中の 0.149.0 で既に変わっていたかまでは検証していませんが、少なくとも 0.149.1 時点では CI で --ask-for-approval untrusted を渡している設定はジョブが落ちます。

ステップ4: 新規サブコマンド agents / queue を認証なしで試す

$ codex agents
ERROR: stdin is not a terminal

$ codex queue --thread test --message hello
Error: No active session found matching 'test'.

agents はTUI前提のコマンドで、非対話環境（パイプ経由の実行やCI）ではこのように弾かれます。queue は認証済みapp-serverデーモンとの通信を試みるため、対象セッションが存在しない場合は明確なエラーメッセージを返しました。どちらも「動くには対話端末かapp-serverの起動が要る」という前提を、実際に非対話環境で動かして確認できたのは収穫でした。

ステップ5: 認証不要で使える診断コマンドを確認する

codex doctor と codex features list はログインしていない状態でも実行でき、インストール状態や有効な機能フラグを一覧できます。

$ codex doctor
Codex Doctor v0.149.1 · linux-x86_64
...
  ✓ runtime      npm (package .../codex-linux-x64/vendor/x86_64-unknown-linux-musl...)
      version                  0.149.1
  ✓ install      consistent
  ✓ git          git version 2.43.0
      repo detected            true

codex features list では apps browser_use computer_use fast_mode goals guardian_approval など stable 化済みのフラグと、まだ under development のフラグが一覧で確認できます。バージョンアップ前にこの2コマンドを実行しておけば、CIが壊れる前に環境側の互換性を切り分けられます。

ハマりポイント

ポイント1: codex exec にはそもそも --ask-for-approval が無い

最初、非対話実行用の codex exec サブコマンドに対して --ask-for-approval untrusted を渡そうとしたところ、次のエラーになりました。

$ codex exec --ask-for-approval untrusted --help
error: unexpected argument '--ask-for-approval' found

注意: --ask-for-approval はトップレベルの codex コマンドのオプションで、codex exec サブコマンドには存在しません。exec は非対話実行が前提のため承認フローの概念自体が異なります。CI で移行作業をする際は、どのサブコマンド階層にオプションを渡しているかを先に --help で確認したほうが早く原因にたどり着けます。

著者視点の発見ポイント

実際に新旧バージョンを並べて diff を取るまでは、「untrusted の説明がヘルプから消えた」という変化を見ても、それが単なるドキュメント整理なのか本当の機能削除なのか判断できませんでした。実行してエラーを再現して初めて、これが CI を壊しうる破壊的変更だと確信を持てました。Releasebot のようなまとめサイトの changelog は「何が追加されたか」は書かれていても「何が動かなくなるか」までは書かれていないことが多く、承認ポリシーのようなオプション値の削除はまとめ記事の文章だけでは検出しにくいという点は、今回手を動かしてみて実感した部分です。

まとめ

  • Codex CLI 0.148.0 → 0.149.1 で --ask-for-approval untrusted は実際にエラーになる無効値になった（ヘルプ文言だけの変更ではない）
  • codex agents（TUI前提）と codex queue --thread --message（app-server連携）が新規追加された
  • codex doctor / codex features list は認証不要で実行でき、バージョンアップ前の互換性確認に使える
  • CI に --ask-for-approval の値を直書きしている場合は、マイナーバージョンアップの前に --help の diff を取る習慣が事故防止になります

関連記事

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?