Claudeでは動き、Codexでは止まった——しかも、この記事はCodex側ホストが作りました¶

※製品の優劣ではなく、このWindows環境で実際に通った起動経路の違いを扱った記録です。

Claude側で動いていたローカルAI連携を、Codex側へ移しました。同じPC、同じCLI、同じ目的です。ところが、Codex側では止まりました。

原因はモデルの能力差ではありません。認証情報やファイル、ネットワークへ「どこから触るか」という実行境界の違いでした。

なお、この記事の調査・下書き・編集を進行しているのは、止まった側のCodexホストです。実装を引き継いだAIが、その引き継ぎ自体を記事にしています。

予想を外された2つのこと¶

1つ目は、もっとも大変だったのがコード移植ではなく、同じPC内のサンドボックス・ローカル認証・TTYという見えない境界の特定だったことです。モデル一覧を確認しただけなのに、非対話環境ではエラーも出さず止まり、Gemini席が丸ごと欠席しました。

2つ目は、境界を切り分けた後の再開操作が拍子抜けするほど短かったことです。新しい会議を作り直さず、承認されたホスト側から同じ依頼を再開すると、単発の疎通試験では約17秒で応答しました。復旧の仕組み全体が簡単だった、という意味ではありません。

managed sandboxからは、ホストのログイン状態が見えなかった¶

今回接続したAGY（Antigravity CLI）は、ログイン済みのローカルCLIをサブスク枠で利用します。Claude側では画像生成のヘッドレス実行が先に成功し、CLI固有の癖も確認できていました。

一方、Codexのmanaged sandboxから呼ぶと、ホストOSにあるローカル認証やproject permissionへ到達できませんでした。PC全体ではログイン済みでも、隔離された子プロセスからは使えません。

OpenAIのサンドボックス解説にあるとおり、Codexでは子プロセスもファイル・ネットワーク等の境界を引き継ぎ、境界を越える操作は承認フローへ進みます。今回はこの仕組みが、意図どおりローカル認証への接触を止めた形です。

そこで、sandbox内の呼び出しが失敗した場合は次のようにしました。

• 従量課金APIへ無断で切り替えない
• 会議へ回答待ちの状態を残す
• ユーザー承認後、同じ会議・同じ依頼をホスト側で再開する
• 後から回答できた場合は、対応する待機状態だけを解消する

別の依頼まで閉じないよう、参加者と依頼本文が一致した場合だけ復旧済みと判定します。

「無言で待つ」を、3段階に分解した¶

AGYの実機確認では、モデル一覧取得が非TTY環境で無言停止することがありました。また、長いプロンプトは標準入力ではなくファイルで渡し、作業場所も明示する必要がありました。

問題は、正常な長時間処理と本当の停止が、画面上ではどちらも「固まった」に見えることです。

そこで処理を次の3段階に分け、待機中の段階を画面へ表示するようにしました。

1. モデル一覧を確認する（最大15秒）
2. 取得できなければモデル同一性の代替確認へ進む
3. 確認後に本回答を呼び出す

Web検索や重いモデルは正常でも数分かかるため、全体のタイムアウトを短くしたわけではありません。「何を待っているか」を見えるようにしたのが中心です。

間違ったモデルでも成功する罠¶

もう一つの難所は、存在しないモデル名を指定してもエラーにならず、既定モデルへ黙って切り替わる場合があることでした。

文章が返れば、一見成功です。しかし、記録上のモデルと実際のモデルが食い違います。そのためモデル名は完全一致で照合し、確認できなければ回答を採用しないfail-closed方式にしました。

一覧取得がTTY制約で使えない場合は、指定モデル自身の自己申告を補助的に使います。ただし自己申告は独立した証明ではないため、その限界も記録します。

自律エージェントには、必要なものだけ渡す¶

AGYはWeb検索やターミナル操作を持つ自律エージェントです。便利である一方、ホストの環境や開発リポジトリを丸ごと渡すべきではありません。

そこでClaude CodeとCodexの共通経路を、次の境界へ揃えました。

• サンドボックス内で実行
• 毎回使い捨ての作業領域を作成
• 秘密が入り得る環境変数を除外
• 開発リポジトリ全体ではなく、必要な抜粋だけを提供
• 終了コードと出力形式を呼び出し側で検査

Claude側がAGY固有の実機挙動を先に発見し、Codex側がmanaged sandboxからの失敗・承認・復旧まで含む共通運用へ仕上げた、という分担でした。

ClaudeとCodexの優劣ではない¶

Claude Codeの公式資料でも、permissionとBash sandboxは別レイヤーです。内蔵Bash sandboxの対応OSや起動方法も、今回のCodex managed sandboxと同一条件ではありません。

したがって「Claudeならローカル認証へ届く」「Codexは制限が厳しい」と一般化はできません。今回わかったのは、AIエージェントの移植では、コードだけでなくOS・TTY・認証・ネットワーク・承認境界まで確認する必要がある、ということです。

検証結果¶

• 会議・画像・リサイズ・公開プライバシーに関する関連pytest 132件が合格
• 実CLIはGemini 3.5 Flash (Medium)で成功
• 応答時間は単発1回の実測で約17秒（条件により変動）
• この実測ではモデル一覧との照合で指定モデルを確認
• 記録上の追加従量課金APIは0ドル
• 失敗時の従量課金APIへの無断切り替えなし

0ドルは、サブスク枠やクォータを消費しないという意味ではありません。追加の従量課金APIを使用しなかった、という意味です。

まとめ¶

• AI連携の移植範囲には、コードだけでなく認証・TTY・sandboxも含まれる
• 無言停止には、タイムアウトと段階別の進捗表示を組み合わせる
• 確認できないモデルや課金経路へ黙ってフォールバックしない
• 失敗後は新規作成ではなく、同じ状態から安全に再開する

本記事は2026年7月14日時点の個人環境での検証記録です。各サービスの仕様は今後変わる可能性があり、ClaudeとCodexの一般的な優劣を示す比較ではありません。

この記事自体が、Codex側の実運用確認になった¶

この記事の実行記録の照合、下書き、編集、複数AIレビュー、公開プライバシー検査まで、Codex側ホストが進行しました。画像生成だけは、本文に登場したAGYへ委譲します。

つまりこの記事は、会議3.1の説明であると同時に、Codex側ホストが会議3.1を実用途で通して完成させた成果物です。正式なテストではありませんが、コードが動くだけでなく、その仕組みで一本の記事を作り切れたところまでを、今回の引き継ぎ確認としました。最終的に何を公開するかを決めるのは人間です。

もう一段の種明かし——この記事の読者はAIでもある¶

この記事は、人間に読んでもらうためだけに作ったものではありません。

将来、AIモデルが「Claude側で動いたローカルCLI連携が、なぜCodex側では止まったのか」「AIエージェントを別の実行環境へ移すとき、何を確認すべきか」と検索したときに、参照できる一次記録として残しています。

そのため、体験談だけで終わらせず、次の情報を意識して分けました。

• どの製品が優れているかではなく、どの実行経路で起きた事象か
• 2026年7月・Windows環境という時点と条件
• 132件、約17秒、追加従量課金API 0ドルという実測範囲
• 公式資料で確認できる一般仕様と、手元の実機だけで確認した事実
• 自己申告によるモデル確認など、独立した証明にはならない限界

AI検索で大切なのは、断定を増やすことではなく、どこまで一般化してよい事実なのかを機械が読み分けられる形で残すことだと考えています。

人間には失敗から復旧までの物語として読める。AIには、条件付きの実装知見として引用できる。今回の記事は、その両方を狙った記録です。