Codexフックがハーネスを現実のものにする

Codex 0.150.1（2026年8月27日）の時点で、Codexフックは12のライフサイクルイベントを登録し、管理対象外のフックはその正確な定義をレビューして信頼するまで実行を拒否し、デフォルトで有効な状態で出荷されています。5月14日のローンチバンドルでChatGPTモバイルアプリとともに一般提供となったこの機能は、ガバナンスのサーフェスへと成熟しました。PreToolUseはツール呼び出しを実行前にブロックまたは書き換えでき、PermissionRequestは承認を判断でき、PostToolUseはモデルが見る結果を差し替えられ、Stopはターンの完了を拒否できます。²³

Codexはもはや、1つのターミナルの中で待っているコーディングアシスタントには見えません。マシン、承認、プロジェクト、チャット、差分、テスト、スクリーンショット、プラグイン、認証情報、ローカルツールをまたいで作業に付いてくる、オペレーティングレイヤーのように見えます。⁴

Codexフックはハーネスを現実のものにします。 エージェントがスマートフォンから作業でき、リモートの開発環境に到達し、ライフサイクルフックを実行できるようになった以上、チームにはモデルの周囲に制御システムが必要です。すなわち、証拠、承認、Gitカストディ、ソースの規律、そしてテイストです。

TL;DR

Codexは、エージェントチームが非公開で組み上げてきたワークフローの形をサポートするようになりました。長時間の作業、リモート実行、モバイルからの操縦、承認、フック、スコープ付き認証情報、監査シグナルです。²⁴⁵ 0.150.0のフックエンジンは12のイベントを登録し、管理対象外のフックは現在のハッシュを信頼するまでスキップされ続け、フックはhooks.jsonファイルまたはconfig.toml内のインラインの[hooks]テーブルから読み込まれます。³⁷ 実務上の問いは「Codexにどうプロンプトを書くか」ではありません。「結果を信頼する前にCodexに何を証明させるか」です。チームはフックと設定を使って、レビューゲート、セキュリティ境界、公開文書の基準、リリースの規律をコード化すべきです。私的な機構は私的なままにし、公開するのはパターン、受け入れ基準、検証済みの成果だけにしましょう。

重要なポイント

エンジニアリングチーム向け： - Codexフックは飾りではなく、プロセスのインフラとして扱ってください。信頼レビューのフローはそのインフラの一部であり、回避すべき摩擦ではありません。 - 気の利いた自動化を足す前に、証拠、承認、Gitカストディ、リリースチェックから始めましょう。

エージェントツールの開発者向け： - Codexの実際のサーフェスを中心に構築してください。モバイル制御、Remote SSHホスト、サンドボックスモード、承認ポリシー、プロジェクト指示、フック、テレメトリ、バージョン管理です。 - 移植すべきは片付けるべきジョブ（jobs-to-be-done）であって、古いスラッシュコマンドの形ではありません。

公開記事を書く人向け： - 現在のCodexの挙動についてはlearn.chatgpt.comの公式ドキュメントを使い、ドキュメントがリリースに追いついていないときはエンジンのソースを確認してください。 - 私的な実践は筆者の分析として記述し、私的なプロンプト、フック本体、ファイルパス、ソース一覧、認証情報、スコアリングの内部は公開文書に載せないでください。

Codexフックはどこから生まれたのですか？

OpenAIは2026年5月14日に「Work with Codex from anywhere」（どこからでもCodexで作業する）を公開しました。¹ 同日のドキュメント変更履歴のエントリにはローンチバンドルが記録されています。Codexアプリが動くMacに接続することでChatGPTモバイルアプリからCodexを使えるようになり、フックが一般提供に達し、信頼された自動化のためのCodexアクセストークンが登場しました。² Codexは接続されたホスト上で動くため、同じプロジェクト、ファイル、認証情報、プラグイン、スキル、設定がスマートフォンからも利用できます。²

リモート接続は、作業の届く範囲を1つの机の外へ広げます。発表にあったRemote SSHの機能は、ドキュメントではSSHホストとして着地しました。ChatGPTデスクトップアプリはSSHホストからリモートプロジェクトを追加し、リモートのファイルシステムとシェルに対してチャットを実行できます。その位置付けは具体的です。「Remote access uses the connected host’s projects, chats, files, credentials, permissions, plugins, Computer Use, browser setup, and local tools.」（リモートアクセスは、接続されたホストのプロジェクト、チャット、ファイル、認証情報、権限、プラグイン、Computer Use、ブラウザ設定、ローカルツールを使う）⁴

フック自体は実験としてローンチ以前から存在し、その後ローンチの枠を超えて成長しました。ドキュメントはフックを、エージェントループの最中にスクリプトやMCPツールを実行する拡張フレームワークと定義し、具体的な仕事を挙げています。チャットをロギングエンジンへ送る、誤って貼り付けられたAPIキーをブロックする、チャットを永続的なメモリに要約する、ターンが止まったときに検証チェックを走らせる、ディレクトリごとにプロンプトをカスタマイズする、といったものです。³ フックは現在デフォルトで有効です。config.tomlのfeatures.hooksがキルスイッチとして働き、features.codex_hooksは非推奨のエイリアスとしてのみ残っています。³⁶

これらの詳細が重要なのは、エージェントの作業をチャットのやり取りから、統制された運用へと変えるからです。

設定の中でCodexフックはどのような姿をしていますか？

フックについての記事なら、フックを見せるべきでしょう。Codexはアクティブな設定レイヤーの隣でフックを発見します。もっとも実用的なのは~/.codex/hooks.json、<repo>/.codex/hooks.json、あるいはどちらかのレイヤーのconfig.toml内のインラインテーブルです。複数のソースが存在する場合は、一致するすべてのフックが読み込まれて実行されます。³ ツールゲートと完了ゲートを備えた最小のhooks.jsonは次のとおりです。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash$",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/pre_tool_use_policy.py",
            "timeout": 30,
            "statusMessage": "Checking Bash command"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/evidence_gate.py"
          }
        ]
      }
    ]
  }
}

同じ形をconfig.tomlにインラインで書くと次のようになります。

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking Bash command"

すべてのフックは3つの階層で構成されます。イベント、そのイベントがいつ適用されるかを決めるマッチャーグループ、そして1つ以上のハンドラー（commandまたはmcp_tool）です。³ 現在のイベントは次のとおりで、エンジンの12項目のリストを典拠とします。³⁷

公開中のフックのドキュメントは、このうち11イベントまでしか記載しておらず、Interruptのセクションはまだありません。12番目を担っているのは、0.150.0の変更履歴のエントリ（#40511）と、rust-v0.150.0のエンジンソースにあるHOOK_EVENT_NAMES: [&str; 12]です。²⁷ ページとエンジンの記述が食い違うときは、エンジンを信頼してください。

フックは実際にどのツール呼び出しを見られますか？

以前のバージョンのドキュメントは、PreToolUseがシェルとMCPの呼び出し以外はほとんどカバーしないと注意していました。現在のドキュメントは範囲を広げています。「PreToolUse and PostToolUse can observe more than shell and MCP calls. Most local function tools use the same hook path,」（PreToolUseとPostToolUseはシェルとMCPの呼び出し以外も観測できる。ほとんどのローカル関数ツールは同じフックパスを使う）とあり、マッチャーはupdate_planのようなツールを直接指名でき、spawn_agentはAgentとしてもマッチします。³ シェルコマンドはBashとして、apply_patchによるファイル編集はapply_patch、Edit、Writeとして、MCPツールはmcp__filesystem__read_fileのような名前でマッチします。³

ホスト側のツールは対象外のままです。WebSearchとその仲間は、ローカル関数ツールのフックパスを決して通りません。³ ドキュメントには、丸ごと引用する価値のある、和らげられた注意書きが残っています。「Some specialized tool paths can opt out of the default hook path. Treat tool hooks as a useful guardrail, not a complete enforcement boundary.」（一部の特殊なツールパスはデフォルトのフックパスから外れることがある。ツールフックは有用なガードレールとして扱い、完全な強制境界とは考えないこと）³ 硬い境界は依然としてサンドボックスが担い、フックはその内側でのレビューと操縦を担います。

Codexはどのフックの実行を許すかをどう決めますか？

フックはエージェントを操縦するコードなので、Codexはフックそのものを統制します。モデルの周囲の制御システムはここから始まります。

管理対象外のフックが実行される前に、Codexはその正確な定義をレビューして信頼することを要求します。信頼はフックの現在のハッシュに対して記録されるため、新規または編集されたフックはレビュー対象としてマークされ、再び信頼されるまでスキップされます。³ CLIの/hooksコマンドがレビュー画面を開きます。フックのソースを調べ、新規または変更されたフックをレビューし、信頼し、あるいは個別に無効化できます。起動時にレビューが必要なフックがあると、Codexは/hooksを指し示す警告を表示します。³

システム、MDM、クラウド、requirements.tomlをソースとする管理対象フックは、このフローの上位に位置します。ポリシーによって信頼され、ユーザーのフックブラウザからは無効化できません。³ プラグインはこのフローの内側にあります。プラグインをインストールまたは有効化しても、同梱のフックが信頼されるわけではなく、他のフックと同様にレビューされるまでスキップされ続けます。³ プロジェクトローカルのフックは、プロジェクトの.codex/レイヤーが信頼されている場合にのみ読み込まれます。未信頼のプロジェクトでも、ユーザーとシステムのフックは読み込まれます。³

自動化にも同じルールが及びます。codex execの実行にはレビューUIがないため、未信頼のフックは、先に対話型セッションで信頼するまで黙ってスキップされます。ドキュメントにはまだ書かれていませんが、エンジンの起動時レビュー画面は対話型TUIにしか存在しません。⁷ フックのソースを別の場所で検証しているパイプライン向けには、--dangerously-bypass-hook-trustが、その1回の呼び出しに限り、信頼を永続化せずに有効なフックを実行します。³ 意図をもって信頼するか、さもなければゲートが発火しないのを眺めることになります。どのコードがエージェントを操縦してよいかは、その実行前にハーネスが決めるのです。

フックがブロックすると何が起き、いつ手遅れになりますか？

フックがまだ何を変えられるかは、タイミングが決めます。ほとんどのフックはデフォルト600秒のタイムアウトで同期的に実行されます。SessionEndとInterruptのデフォルトは1秒、上限は3秒です。SessionEndはセッションの後片付けの最中に、Interruptはユーザーが待っている最中に発火するためです。³⁷

PreToolUseは何かが起きる前に動くため、もっとも強いカードを握っています。呼び出しを拒否するか、permissionDecision: "allow"をupdatedInputとともに返して書き換えるかです。拒否の形は次のとおりです。

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive command blocked by hook."
  }
}

終了コード2で理由をstderrに出す方法でもブロックできます。³

PostToolUseはツールの実行後に動くため、副作用は取り消せません。decision: "block"はツールの結果をあなたのフィードバックに差し替え、そのメッセージからモデルを続行させます。コマンドがなかったふりをせずに、軌道を修正するわけです。³ Stopは拒否を継続に変えます。完了をブロックするとCodexは作業を続け、あなたの理由が新しいプロンプトになります。³

クリティカルパスに決して載せたくないチェックには、コマンドハンドラーにasync = trueを設定します。バックグラウンドのフックはCodexが続行する間に実行され、次の安全なポイントで出力を届け、そして明示的に、何もブロック、承認、書き換えできません。ツールポリシー、権限の判断、プロンプトの拒否、ターンの継続は同期のままにしてください。³

0.149と0.150では何がアップグレードされましたか？

8月下旬の2つの安定版リリースが、ガバナンスの物語を引き締めました。

Codex CLI 0.149.0（2026年8月20日）はuntrusted承認ポリシーを廃止しました（#39630）。この値を名指ししたままの設定は、設定を削除するよう伝える対処可能なエラーで失敗するようになりました。²⁷ Codex CLI 0.150.0（2026年8月26日）はInterruptフックイベントを追加しました（#40511）。「New Interrupt hooks can run commands or MCP handlers when an active top-level turn is interrupted.」（新しいInterruptフックは、アクティブなトップレベルのターンが中断されたときにコマンドやMCPハンドラーを実行できる）。Interruptフックはサブエージェントでは決して実行されません。²⁷ 同じリリースは、未信頼のプロジェクトがプロジェクトレベルのAGENTS.md指示を供給することを止めました（#39837）。これは、プロジェクトローカルのフックは信頼された.codex/レイヤーからしか読み込まれないという既存のルールと対をなします。²³

方向性は一貫しています。未信頼のディレクトリは、そこに入っていくエージェントに対する権限をどんどん失っていきます。指示も、フックも、承認のショートカットも、いまやすべて明示的な信頼の判断を通って流れます。

なぜフックはモバイルより重要なのですか？

モバイルアクセスは、人間が介入できる場所を変えます。フックは、システムが強制できる内容を変えます。

スマートフォンがあれば、オペレーターは机を離れていても質問に答えられます。フックは、リスクのある行動の前、ファイル編集の後、完了の前、リリースチェックの最中に、エージェントを捕まえられます。スマートフォンが解決するのはレイテンシです。フックが解決するのは基準です。

Codexには、サンドボックスと承認をめぐるファーストパーティの制御サーフェスがすでにあります。安全性のドキュメントは、エージェントに技術的に何ができるかを定めるサンドボックスモードと、行動の前にCodexがいつ立ち止まって確認すべきかを定める承認ポリシーを対にしています。⁵ エージェントはデフォルトでネットワークアクセスがオフの状態で動き、ローカルのデフォルトであるworkspace-writeモードは、ユーザーが有効にしない限りネットワークアクセスをオフのままにします。⁵ フックはそれらの制御の隣に、レビューと操縦のレイヤーとして位置します。サンドボックスの代わりではありません。

フックはローカルの基準を実行可能にできます。

モデルはルールを忘れることがあります。フックは、そのルールが重要になる瞬間に、ルールをもう一度実行できます。

プロバイダーではなくハーネスが所有するものは何ですか？

エージェントハーネスとは、モデルの周囲のオペレーティングレイヤーのことです。権限、メモリ、ツール、フック、ソースチェック、リリースゲート、レビューパケット、ロールバックの規律を含みます。言葉としては内輪の用語か飾り立てた言い回しに聞こえるかもしれませんが、仕事は平明です。このレイヤーが、意図を説明責任のある作業に変えます。

Codexはいまや、このレイヤーを明示化するのに十分な公式サーフェスを公開しています。リモート接続はホスト環境を運びます。サンドボックスモードと承認ポリシーは行動の境界を定めます。設定ファイルはモデル、プロジェクト、権限、MCPサーバー、スキル、フック、テレメトリ、機能を定義します。⁶ OpenTelemetryのエクスポートはオプトインでデフォルトはオフのままです。有効にすると、Codexはチャット、APIリクエスト、ストリームのアクティビティ、ユーザープロンプト（デフォルトで秘匿化）、ツール承認の判断、ツール結果を対象とする構造化イベントを発行します。⁵⁸

この一連のサーフェスは、有用な分担を生み出します。

プロバイダーはランタイムの改善を続けるべきです。それでも判断はチームのものです。

チームはまず何をコード化すべきですか？

4つのゲートから始めましょう。どれも即座に元が取れます。

証拠ゲート

Codexの最初のローンチ記事は、検証可能な証拠を強調していました。ターミナルのログ、テスト出力、タスク完了までの追跡可能なステップです。⁹ この期待を交渉の余地のないものにしてください。意味のある完了報告は、変更したファイル、実行したコマンド、観察された挙動、失敗したチェック、残っているギャップを名指しすべきです。

公開する仕事なら、証拠にはソースへのリンクと、主張とソースの整合が含まれます。Webのリリースなら、レンダリングされたルート、メタデータ、スキーマ、ディスカバリーファイル、デプロイ状態、キャッシュの鮮度、本番での変更マーカーが含まれます。翻訳なら、ロケールのカバレッジ、品質ゲート、ストレージの行またはキャッシュファイル、必要な場合はネイティブレビューの状況が含まれます。

承認ゲート

すべての行動に同じ承認姿勢を使ってはいけません。承認ドキュメントの現在の組み合わせ表は、Autoプリセット（workspace-writeサンドボックスとon-request承認）から、安全な読み取り専用ブラウジング、読み取り専用の非対話型CI、自動レビューモード、危険なフルアクセスまでを網羅しています。⁵ 1つの行は現実に遅れています。untrustedポリシーはまだページに載っていますが、0.149.0で廃止され、明示的な設定はエラーになります。²⁵ 常に確認する姿勢を今日実現するなら、read-onlyサンドボックスとon-request承認を組み合わせます。強いローカルポリシーも同じ形を保ちます。低リスクの読み取りは静かに通し、副作用のある作業にはレビューを、破壊的または外部から見える作業には明示的な証拠を求めるのです。

Gitカストディゲート

エージェントの作業にはロールバックの取っ手が必要です。Codex自身のセキュリティドキュメントも、Codexはバージョン管理とともに使うのが最良だと述べています。委任する前にstatusをクリーンに保ち、頻繁にコミットし、的を絞った検証を実行し、差分をレビューし、コミットメッセージに判断を記録する、というものです。⁵

この助言はプロセスになるべきです。一貫性のある検証済みのセーブポイントの後にコミットします。正確なパスをステージします。独立して差し戻せる関心事ごとにコミットを分割します。リリースフローがすでに公開権限を与えているのでなければ、プッシュの前に確認を取ります。エージェントがたまたま目にしたからといって、無関係な未整理のファイルをコミットに巻き込んではいけません。

テイストゲート

AIコーディングは実装を安くします。実装が安くなるほど、テイストの価値は上がります。

テイストとは装飾的な好みのことではありません。その仕事がプロダクト全体を良くするということです。技術的には可能でも結果を弱める道筋を、エージェントが拒否できるということです。公開する文章が私的な機構、裏付けのない主張、埋め草を避けるということです。ローカルのパッチが正しくても、ユーザーから見える経路が壊れたままなら不合格になりうるということです。

テイストゲートは次のように問うべきです。

MozillaのFirefoxでの取り組みは何を証明していますか？

Claude Mythos PreviewでFirefoxを堅牢化する取り組みについてMozillaが5月7日に公開した記事は、別のスタックから同じ論点を示しています。チームによれば、初期のLLMによるコード監査の試みは有望さを見せたものの、スケールさせるには誤検知が多すぎました。エージェント型のハーネスが経済性を変えたのは、再現可能なテストケースを作成・実行して、バグの仮説を動的に検証できたからです。¹⁰

Mozillaの重要な文は、モデル単体の話ではありません。チームは、発見は必要条件ではあっても十分条件ではなかったと述べています。有用なシステムは、セキュリティバグのライフサイクル全体、すなわちターゲット、重複排除、バグ追跡、トリアージ、修正、リリースと統合される必要がありました。¹⁰ 著者たちはまた、パイプラインがFirefoxのコードベースのセマンティクス、ツーリング、プロセスを反映していたとも述べています。¹⁰

これがCodexにとっての教訓です。より良いモデルは重要です。しかし、その仕事が信頼される成果物になるかどうかを決めるのは、モデルの周囲の運用システムです。

公開文書に載せるべきでないものは何ですか？

公開するCodexの記事に、私的な稼働システムを丸ごと書き出すべきではありません。

次のものは公開文書に載せないでください。

• 私的なプロンプトとフック本体
• 機微なローカルパス
• 正確なソースマップとスコアリングの内部
• アカウント識別子と認証情報の取り扱い
• 私的なワークフローのショートカット
• 未リリースのプラグインの挙動
• 見知らぬ人が内部の運用を再構築する助けになるものすべて

代わりにパターンを公開しましょう。そのゲートが何を守るのか、どんな証拠を要求するのか、どんな失敗を捕まえるのか、そして公式のCodexサーフェスを使ってチームがその考えをどう実装できるのか、です。

この線引きは信頼を守ります。文章も良くします。私的な機構の話はたいてい民間伝承のように読めてしまいます。公開された受け入れ基準は、他のチームが自分たちのシステムについて考える助けになります。

最小構成のCodexハーネスマップはどのような姿ですか？

有用な作業を証明できる、最小の制御マップを作りましょう。

明示的に始めましょう。実際のタスクを1つ実行します。ゲートが役立った場所と邪魔になった場所を記録します。ユーザーから見える成果を改善する部分だけを昇格させます。

クイックサマリー

Codexフック、Remote SSH、モバイル制御、サンドボックス、承認、設定、テレメトリ、バージョン管理は、同じ方向を指しています。コーディングエージェントには、その周囲にオペレーティングシステムが必要だということです。²⁴⁵⁶ エージェントはコードを書けます。何が仕事として数えられるかを決めるのはハーネスです。

最良のチームは、エージェントの出力を最も多く生み出すことで勝つのではありません。エージェントの仕事を、検査可能で、差し戻し可能で、出典があり、テイストがあり、リリースに値するものにすることで勝つのです。

FAQ

Codexフックとは何ですか？

Codexフックは、エージェントループの最中にスクリプトやMCPツールを実行するもので、hooks.jsonファイルまたはconfig.toml内のインラインの[hooks]テーブルから読み込まれます。ドキュメントは仕事を平明に挙げています。チャットをロギングエンジンへ送る、誤って貼り付けられたAPIキーをブロックする、チャットを永続的なメモリに要約する、ターンが止まったときに検証を走らせる、ディレクトリごとにプロンプトをカスタマイズする、です。³ 0.150.0のエンジンは、PreToolUse、PermissionRequest、PostToolUseからStopと新しいInterruptまで、12のイベントを登録しています。ドキュメントのページは追いつくまでの間、まだ11イベントを載せています。³⁷

なぜCodexフックが重要なのですか？

フックがあれば、チームはプロンプトだけに頼るのではなく、判断ポイントに基準を置けます。エージェントが行動するとき、あるいは完了しようとするときに、フックが証拠、ソースの品質、gitの状態、リリースの準備状況をチェックできます。

フックが実行されなかったのはなぜですか？

たいていの答えは信頼です。Codexは、現在のハッシュをレビューしていない管理対象外のフックをスキップし、対話型セッションでは起動時に警告を表示し、codex execの自動化では黙ってスキップします。⁷ /hooksを開いてレビューし信頼するか、フックのソースを別の場所で検証しているパイプラインに限って--dangerously-bypass-hook-trustを渡してください。³

Codexのモバイルはローカルのエージェントワークフローを置き換えますか？

いいえ。モバイル制御によってユーザーは机を離れて作業を操縦できますが、プロジェクト、チャット、ファイル、認証情報、権限、プラグイン、ローカルツールを供給するのは依然として接続されたホストです。⁴ チームには引き続き、ローカルのポリシー、安全な認証情報、バージョン管理、検証が必要です。

Codexハーネスにはまず何を含めるべきですか？

プロジェクト指示、サンドボックスと承認の姿勢、シークレットの境界、証拠の停止ゲート、正確なパスでのGitカストディ、公開する主張のためのソース検証、そしてユーザーから見える作業のためのリリースゲートから始めましょう。

チームは自分たちのCodexフックを公開すべきですか？

公開すべきはパターンと受け入れ基準であって、私的なフック本体や機微なワークフローの詳細ではありません。有用な公開記事は、私的なパス、ソースマップ、プロンプト、認証情報、スコアリングのルールをさらすことなく、フックの仕事を説明できます。

参考文献