Codex CLI 0.112.0→0.114.0 で権限設計が変わった。request_permissions が実務で効く理由

関連記事としては Blog2秒 vs 15秒：Codex・Claude Code・Grok、通常セッションの最適モデルを実測で選ぶCodexのGPT-5.6 Terra High、Claude CodeのSonnet 5 High、Grok 4.5 Highを、第三者実測のタスク単価・知能指標・応答開始時間で比較。通常セッションと難問での切り替え基準を整理します。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

3行まとめ: 0.112.0 で土台を固め、0.113.0 で request_permissions（実行中の段階的権限要求）が追加、0.114.0 で experimental code mode・hooks・承認フロー修正が入った。「権限まわりが怖い」を減らす方向に、3バージョン通じて筋が通っています。

正直に言うと、今回の Codex CLI の更新は「細かい改善が少し入った」程度ではありません。

0.112.0 から 0.114.0 までの数日間で、Codex はかなりはっきりと「安全に権限を扱いながら、実行中に必要なものを取りに行けるエージェント」に寄ってきました。

しかも厄介なのが、表面だけ見ていると変化が散って見えることです。@plugin、request_permissions、permission profile、app-server、code mode、hooks。単語だけ並ぶと「なんか色々増えたな」で終わるのですが、流れで見ると結構筋が通っています。

今回は、公式の Codex changelog と GitHub の release notes を見ながら、Codex CLI 0.112.0、0.113.0、0.114.0 の3つをまとめて、「結局どこが重要なのか」と「実際の運用でどこが楽になるのか」を実務目線で整理します。

3バージョンを並べると、役割はかなり分かれています。

なので、「0.112.0 から 0.114.0 に上げて何が変わった？」と聞かれたら、私はまずこう答えます。

「見た目以上に、権限要求とツール実行の設計が進んだ」です。

ここを理解すると、今回のアップデート全体が見やすくなります。

0.112.0 で入った新機能の中で、分かりやすいのは @plugin メンションです。

これでチャット中にプラグインを直接参照しやすくなり、関連する MCP / app / skill の文脈を自動で取り込みやすくなりました。要するに「使いたい拡張機能を会話の中で雑に呼びやすくなった」という話です。

ただ、個人的には本当に効いているのはその周辺です。

• モデル選択UIの更新
• zsh-fork 系スキル実行での権限プロファイル統合
• JS REPL の失敗後も既存バインディングを維持
• emitImage の受け入れを data: URL のみに制限
• Linux / macOS サンドボックスの挙動改善

この辺は、一つひとつは地味です。

でも、こういう地味な修正がないままエージェントだけ賢くなると、実際の運用はすぐ壊れます。DIYでもそうですが、派手なアタッチメントを先に足すより、土台のガタつきを潰す方が先です。Codex もこの段階ではまだ「広げる前の足場固め」をやっていた印象があります。

📎 0.112.0 リリースノート（GitHub）

ここが今回の本丸です。

0.113.0 で追加された request_permissions は、実務でかなり意味があります。

今までのエージェント系ツールは、最初に渡された権限の中で頑張るか、足りなくなったら人間が全部やり直す、みたいなケースが多かったんですよね。これが地味に面倒でした。

request_permissions が入ると、実行中のターンで「この作業には追加権限が必要です」と段階的に要求できるようになります。しかも TUI 側もその承認表示に対応したので、何を求められているのかが前より分かりやすい。

この差は大きいです。

なぜかというと、AI エージェントを怖く感じる理由のひとつが「最初に広い権限を渡しがち」だからです。必要になるか分からないのに、あらかじめ全部許可するのは気持ち悪い。request_permissions は、その違和感をかなり減らします。

さらに 0.113.0 では、その周辺もまとめて強化されました。

• curated plugin marketplace
• plugin/list
• plugin/uninstall
• インストール時の認証チェック
• Web 検索ツールの詳細設定
• 新しい permission-profile 設定言語
• filesystem / network の分離ポリシー

たとえば config.toml で権限プロファイルを定義するとこんな形になります。

# config.toml（抜粋）
[permissions]
profile = "workspace-write"  # 作業ディレクトリへの書き込みを許可
network_access = false       # ネットワークアクセスは初期無効

request_permissions はこのプロファイル外の操作が必要になったとき、実行ターン中に TUI 上で追加承認を求めてくる仕組みです。

このあたりをまとめると、Codex が「ただツールを叩く存在」から、「何を、どこまで、どういう条件で使うかを制御できる存在」に近づいています。

エージェントは賢くなるだけでは足りません。制御できない賢さは、運用ではだいたい面倒です。ここをちゃんと整えにきたのは良い流れです。

ここは、AIツールの進化と一人開発の可能性について考えるときにも地続きの話です。AIツールが強くなったのは確かですが、本当に効くのは「賢いこと」より「任せても怖くないこと」です。

ちなみに、Codex CLI のセキュリティ上の注意点が気になる方はBlog3秒で終わる攻撃、Claude Code と Codex CLI に潜んでいた3つの穴git cloneして起動するだけでAPIキーが流出していた——Claude CodeとCodex CLIに存在した3つのCVEの仕組みを解説。CVE-2026-21852・CVE-2025-59536・CVE-2025-61260はいずれも修正済み。バージョン確認方法と30秒でできる安全確認手順も紹介。→も参考になります。

これは changelog を読んで感じた話ではなく、今回この原稿を META-MARK のブログパイプラインに流し込む途中で実際に思ったことです。

記事を下書きに入れようとしたとき、Codex が benchmark-db/scripts/generate-blog-posts.ts の保存処理を見て、「これ published: true で upsert していますよ」と拾いました。実際、そのせいで最近のブログが速攻で公開されていた。ここ、かなり生々しい学びでした。

一方で、段階的に権限を要求してくる形だと話が違います。

今回も、いきなり公開まで走らせるのではなく、「まず下書き登録だけ」「次にプレビューHTMLを書き出す」「必要なら公開だけ別に許可する」という順番で切れました。20年ぐらい現場で機器や権限まわりを触っていると、危ない運用はだいたい“便利だから全部開ける”から始まるので、私はこの方向の方がずっと好きです。

要するに request_permissions の価値は、機能が増えたことではありません。AI に少しずつ仕事を渡せるようになったことです。ここは大きいです。

0.113.0 でもうひとつ見逃しにくいのが、app-server の強化です。

具体的には、exec で stdin / stdout / stderr のストリーミング、TTY / PTY 対応、さらに in-process app server path への接続が入りました。

この辺は一般ユーザー向けの派手な機能ではありません。ただ、CLI を本気で道具として使う人には結構重要です。

ターミナル実行が雑だと、途中経過が見えない、対話的なコマンドに弱い、TTY 前提の挙動で壊れる、といった不満が出やすい。つまり「AIは賢いのに、最後の実行基盤が弱い」という状態になるわけです。

ここが強くなると、Codex は単なる文章生成ではなく、かなりちゃんとした作業エージェントに寄ってきます。

このあたり、昔の自動化ツールにありがちだった「exec したけど、実戦では何か足りない」が少しずつ減っている感じがあります。今の開発ツールはモデル性能だけではなく、周辺の実行体験で差がつく段階に入っています。

📎 0.113.0 リリースノート（GitHub）

0.114.0 で追加された目玉は、experimental な code mode と hooks engine です。

正直、この時点ではまだ「全員が明日から必須」という種類の機能ではありません。ですが、方向性はかなり分かりやすいです。

experimental code mode

これは、より隔離されたコーディングワークフローのための実験機能です。

つまり Codex が、ただ会話の延長でコードをいじるだけでなく、「コード作業専用の文脈」を持ち始めているということです。ここは今後たぶん効いてきます。

hooks engine

SessionStart と Stop を持つ hooks engine も同じです。

セッション開始時や停止時に何かを差し込めるなら、チームごとのルール、監査、初期化、後片付けがやりやすくなります。まだ experimental ですが、企業利用や複雑な運用ではむしろこっちが本命かもしれません。

app-server の health check

WebSocket app-server に GET /readyz と GET /healthz が追加されたのも、派手さはないですが運用上は助かります。

こういうところがあると、外から見た監視と生存確認がやりやすい。インフラを触る人ほど「あって当然だけど、無いと困る」やつです。

新機能もありますが、実務目線だと 0.114.0 の価値はむしろ修正群の方が大きいです。

たとえば今回直されたのは、こんなところです。

• Linux の tmux クラッシュ
• 非対応セッションで apps が有効化される問題
• 中断後に再開したスレッドが in-progress で固まる問題
• 旧 workspace-write 挙動との互換性
• 権限承認がターンをまたいで保持されない問題
• apply_patch が承認フローを正しく尊重しない問題

このへん、全部「壊れると地味に腹が立つ」やつです。

しかも性質が悪いのが、再現条件が限定的で、普段は見えないことです。だから changelog を流し見すると軽く見えるのですが、当たる人にはかなり痛い。

特に承認フローまわりは、0.113.0 で大きく広げた機能を 0.114.0 でちゃんと締め直している印象があります。新しい仕組みを入れて終わりではなく、ターン跨ぎや古いビルドとの整合まで詰めているのは良いです。

📎 0.114.0 リリースノート（GitHub）

私はこう見ています。

A. 一般的な CLI 利用者

一番効くのは request_permissions と、その後の承認フロー修正です。

「権限を絞ったまま始めて、必要な時だけ追加で許可する」がやりやすくなったので、精神的にも運用的にもかなりまともになりました。

A. プラグインや拡張を触る人

plugin/list、plugin/uninstall、認証チェック、メンション改善あたりが効きます。拡張機能を“雑に積む”のではなく、“整理して運用する”方向に進んでいます。

A. チーム運用・自動化寄りの人

permission profile、hooks、health check、app-server 強化が効きます。ここは今後の伸びしろを感じます。

Codex CLI の 0.112.0 → 0.114.0 は、単なる小刻みアップデートではありませんでした。

0.112.0 で土台を締め、0.113.0 で権限要求と実行基盤を大きく前進させ、0.114.0 で experimental な方向性を見せつつ承認まわりの信頼性を上げた。そう見ると、かなり筋の良い流れです。

AI ツールの進化って、どうしても派手なモデル名やデモに目が行きます。でも実際に使い続けると、効いてくるのはこういう「壊れにくい」「許可が分かりやすい」「運用しやすい」です。

そこが進んだのなら、今回の更新は見た目よりずっと価値があります。最近のAIツールは「便利になった」で片付けるには少し強くなりすぎました。

少し前なら「AI エージェントにここまで任せるのはまだ早い」と言えた場面も多かったんですが、最近はもう、その線引き自体が静かに塗り替わってきています。

権限を段階的に要求されるようになって、確かに安心感は増しました。でも同時に、「AIに何を任せて、何を任せないか」を人間が判断し続けることが前提になってきた、とも感じます。その判断が当たり前になっていく感覚は、少し面白い。でも少しだけ、息苦しいです。

Q. request_permissions はどこで確認できますか？
A. GitHub のリリースノート（0.113.0）と公式 Codex changelog に詳細があります。TUI 上での承認表示が対応しているため、実行中に「どの権限を追加するか」がダイアログ形式で確認できます。

Q. code mode と通常モードは何が違いますか？
A. code mode はコーディング専用に隔離された文脈を持つ experimental な機能です（0.114.0追加）。通常モードが会話の延長でコードをいじるのに対し、code mode は作業環境を分離して扱います。まだ実験段階なので、本番利用は安定版を待つのが無難です。

Q. 0.114.0 の不具合修正で一番重要なのはどれですか？
A. 権限承認がターンをまたいで保持されない問題と、apply_patch が承認フローを尊重しない問題の2つが実務上はクリティカルです。request_permissions を 0.113.0 で入れて、0.114.0 で締め直しているのは良い流れです。

Q. 旧バージョンから 0.114.0 にアップグレードしても設定は引き継がれますか？
A. workspace-write の旧挙動との互換性が 0.114.0 で修正されています。config.toml を使っている場合は permission profile の設定言語が変わっているため確認してください。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！

• Blog2秒 vs 15秒：Codex・Claude Code・Grok、通常セッションの最適モデルを実測で選ぶCodexのGPT-5.6 Terra High、Claude CodeのSonnet 5 High、Grok 4.5 Highを、第三者実測のタスク単価・知能指標・応答開始時間で比較。通常セッションと難問での切り替え基準を整理します。→
• Blog「effortは高いほど良い」は間違い。GPT-5.5の5段階を実務で使い分ける判断基準GPT-5.5のreasoning.effortパラメータ（none〜xhigh）の選び方を実務翻訳。Responses APIとChat Completions APIの書き方の違い、思考過多トラップの回避、タスク別の判断フローを整理します。→
• BlogAPIの値段が倍になったGPT-5.5。でも実質コストは20%増？その計算根拠GPT-5.5のAPI価格は2倍でも、token効率40%削減を入れると実質コストは約20%増。Codexでの使い分け判断を整理します。→