Codexの作業が止まったセッションでは実行権限が変わっていた
目次
Codexに任せていた作業が、途中から説明と準備の出力にとどまり、進まなくなった。
追加の指示に応答は届くが、外部接続が必要な処理へ進まない。
Macに残ったセッション履歴を確認したところ、同じ会話の途中で実行権限（ツールやコマンドに許可された制限範囲）が変わっていた。
以前はネットワークを使えていたが、再開後は制限付きに切り替わっていた。
指示内容や接続先などの固有情報は伏せ、権限推移とエラーログ、引き継ぎ後の結果を記録しておく。
返事は届くのに作業が進まない
2026年10月4日から7日にかけて使っていた会話を確認した。
この会話では、ローカルでの準備は進んでいたものの、外部サービスを使う段階で拒否され、未完了の操作を残したまま応答が終わっていた。
MCP（Model Context Protocol）は、Codexから外部のツールやサービスを呼び出す仕組みだ。
停止前後のログには、MCP経由のツール呼び出しで次のエラーが残っていた。
MCP tool call requires approval, but approval policy is never外部接続のコマンドにも Operation not permitted が記録されていた。
接続操作自体がOS側ではなくCodexのサンドボックスによって弾かれており、接続先からの認証エラーではなかった。
未完了を伝える返事の後に task_complete の記録もあった。
返事が終わっても作業全体は完了しておらず、実際のツール実行結果を確かめる必要があった。
会話の途中で変わっていたネットワーク権限
セッション履歴には、ターン（指示を受けてから応答を終えるまでの1処理）ごとの実行条件を記録する turn_context が残っていた。
ここには、その時点のモデルや承認方針、実行制限が保存される。
10月5日までの記録と7日の再開時、引き継いだ新しい会話を比べると次のようになった。
| 場面 | sandbox_policy.type | コマンドのネットワークアクセス |
|---|---|---|
| 元の会話、10月5日 | danger-full-access | 有効 |
| 元の会話、10月7日の再開時 | workspace-write | 制限あり |
| 引き継いだ新しい会話、10月7日 | danger-full-access | 有効 |
なお、approval_policy は全場面で never（承認を求めない設定）のままだった。
danger-full-access はローカルのサンドボックス（隔離環境）の制限を外す設定で、workspace-write は作業ディレクトリなどへの書き込みを許可する設定だ。
OpenAIの承認・セキュリティ文書によると、標準の workspace-write は設定で明示的に有効化しない限りネットワークアクセスが無効になる。
再開時のログには network_access: false が明記されていた。
権限プロファイル側も restricted となっており、同じ会話の途中から実行条件が制限付きへ変わっていた。
approval_policyのneverが意味する範囲
全場面で一貫していたのが approval_policy: never だ。
名前からすると承認なしで何でも実行できるように思えるが、これはあくまで実行時にユーザーへの確認を求めるかどうかの設定だ。
OpenAIの承認・セキュリティ文書では、never は各サンドボックスモードと組み合わせて使える。
承認の問い合わせを止めても、設定された実行制限は残る。
Macで停止したときは、ツール側が承認を必要としているにもかかわらず、実行側が承認を求めない設定になっていたため、問い合わせを経ずに呼び出し自体が拒否されていた。
こちらから会話で続行を指示しても、その後のツール呼び出しは同じエラーで弾かれていた。
OpenAIの権限文書では、ローカルコマンドの権限と、MCPやコネクター（外部連携機能）の制御は別々に扱われている。
モデルへの通信設定もコマンド実行とは別系統のため、コマンドの外部接続が制限されていても、Codexから返事が届く動作とは辻褄が合っている。
ログに残っていた通信切断
直近の別セッションには、モデルの返答を受け取る通信が途中で切れた記録もあった。
WebSocket通信のログでは、応答完了を示す response.completed より先に接続が閉じていた。
websocket closed by server before response.completed別の切断では、接続が60分の上限に達したログも出ていた。
OpenAIのWebSocket Mode文書にも、Responses APIの接続は最大60分で、上限に達したら再接続すると記載されている。
新しい会話への引き継ぎと残りの作業
10月7日には、未完了の操作と最後のエラーを整理して、新しい会話へ作業を引き継いだ。
引き継ぎ先ではネットワークアクセスが有効になっており、元の会話で止まった外部操作も進んだ。
ツールの実行結果と最後の報告の両方に、残りの作業を完了した記録がある。
モデルは元の会話も引き継ぎ先も gpt-6.1-sol（推論設定 xhigh）で同一だった。
セッション作成時に記録されたCLIバージョンは、元の会話が0.160.0、引き継ぎ先が0.160.1だった。
同じ現象を調べる場合、会話本文に加えて、その時点の実行条件（turn_context）とツールのエラーログを残しておくと原因を特定しやすい。
OpenAIのトラブルシューティング文書には、セッション履歴の標準保存先として ~/.codex/sessions が案内されている。