VS Code の PowerShell で Codex が途中で落ちる件を調べた

Windows 環境で Codex CLI を使っていると、対話の途中で突然終了し、何事もなかったように PowerShell のプロンプトへ戻ることがありました。
私の環境では Linux は使っておらず、VS Code の統合 PowerShell 上で利用しているときに発生しました。

症状としては、Codex は最初の数回の応答までは普通に返してくれるのに、数ターン後に突然落ちます。終了時には TUI の表示が少し画面に残り、きれいにクリーンアップされずにプロセスだけ消えたような見え方になります。これは GitHub の既報ともかなり一致しています。実際、codex-cli 0.114.0 で「数回の通常対話のあと、PowerShell に戻る」「TUI のステータス表示が残る」という報告があり、PowerShell の -NoProfile でも再現していたため、単純なプロファイル汚染だけでは説明できません。

結論からいうと

現時点では、原因はひとつではなく、Windows 上の Codex と PowerShell / 統合ターミナル / sandbox の組み合わせで起きる不安定性 と考えるのがいちばん自然です。
公式ドキュメントでも、Windows では native sandbox を使い、config.toml で elevated と unelevated を切り替える設計になっています。OpenAI は elevated を推奨しつつ、環境によっては unelevated をフォールバックとして使うよう案内しています。つまり最初から、Windows では環境差の影響を受けやすい構成です。

加えて、2026年3月には Windows 上で「対話途中に PowerShell へ戻る」事例が報告され、同じ issue では sandbox = "elevated" が早期終了を引き起こし、unelevated にすると少し改善したものの、完全には直らなかったと書かれています。ログにも明確なエラーが残らないケースがあり、ユーザー視点ではかなり追いにくい不具合です。

私の見立て

Linux を使っていないなら、まず疑うべきは WSL ではなく Windows ネイティブ経路そのもの です。
今回のように VS Code の統合 PowerShell 上で落ちるなら、主犯候補は次の3つです。

ひとつ目は VS Code 統合ターミナルと PowerShell の相性 です。2026年4月には、Codex の integrated terminal で PowerShell を使うと起動時にクラッシュする issue も出ています。そこでは pwsh.exe 自体は cmd.exe からだと正常に動く一方、Codex integrated terminal 上だけで落ちるとされており、PowerShell そのものより「Codex 側が作る PowerShell セッション」が怪しいことを示しています。

ふたつ目は Windows sandbox モード です。公式には elevated が推奨ですが、実際の報告では elevated が早期終了の原因になり、unelevated に変更すると挙動が改善した例があります。逆に環境によっては unelevated より elevated のほうが安定する可能性もあり、ここはかなりマシン依存です。

みっつ目は PowerShell ホスト起動段階の不具合 です。2026年3月には、Codex が起動した PowerShell が ConsoleHost.Start や UnmanagedPSEntry.Start 付近で失敗する報告もありました。これは「コマンド実行中に落ちる」というより、PowerShell セッション生成そのものが不安定なケースです。

試す価値が高かった切り分け

1. VS Code 統合ターミナルをやめて外部端末で試す

最初にやる価値が高いのはこれです。
外部の PowerShell や Windows Terminal では安定し、VS Code 統合端末だけで落ちるなら、かなり原因を絞れます。実際、統合ターミナル特有の問題は別 issue として報告されています。

2. `~/.codex/config.toml` の sandbox を切り替える

Windows では次の設定が使えます。

[windows]
sandbox = "elevated"

または

[windows]
sandbox = "unelevated"

OpenAI の公式案内では、通常は elevated を推奨しつつ、native sandbox がうまく動かない環境では unelevated を使うよう書かれています。つまり、ここは「正解が一つ」ではなく、実機で試すしかないポイントです。

3. PowerShell のプロファイル影響を切る

よくある切り分けとして powershell -NoProfile は有効です。
ただし今回の既報では、-NoProfile でも再現していたため、これで直らないからといって「自分の環境だけの問題」とは限りません。むしろ、プロファイルを疑っても説明できない種類の不具合が Windows 側で起きている可能性があります。