Codex CLI 0.145.0 on Windows: silent process termination on code-mode functions.exec with nested shell_command calls

Open 💬 0 comments Opened Jul 25, 2026 by JoDevelop1

What version of the Codex App are you using (From “About Codex” dialog)?

codex-cli 0.145.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows [version 10.0.26200.8894]

What issue are you seeing?

<html>
<body>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="37:1-37:330;1020-1349">The Codex CLI process terminates silently in the middle of a task. There is no panic, no error message, no interrupt, and no clean-close event. The process simply disappears, and because the TUI never gets a chance to run its teardown, leftover status text remains rendered on screen while the shell prompt returns underneath it.</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="39:1-39:230;1351-1580">I debugged this with Codex itself, correlating the rollout JSONL, the local sqlite log database, the Windows event logs, and process IDs. I reproduced two separate silent exits, and in both cases the failure boundary is the same.</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="41:1-41:128;1582-1709"><strong>The failure boundary is not PowerShell and not the project commands. It is the code-mode runtime handling <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">functions.exec</code>.</strong></p>

<h3 dir="ltr" class="text-text-100 mt-2 -mb-1 text-base font-bold" data-sourcepos="43:1-43:30;1711-1740">Reproduction 1 — 12:02:43</h3>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="45:1-45:102;1742-1843">Codex emitted a custom <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">functions.exec</code> call whose JavaScript invoked a nested <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">tools.shell_command</code>:</p>

<div role="group" aria-label="Code" tabindex="0" data-sourcepos="47:1-49:4;1845-1944" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">npm run typecheck; node --test test_lighthouse_runner.mjs; python -m unittest test_agent.py</code></pre></div></div>

<ul dir="ltr" class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3 print:block print:space-y-1" data-sourcepos="51:1-54:141;1946-2234">
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="51:1-51:39;1946-1984"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">pwsh.exe</code> was spawned successfully.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="52:1-52:59;1985-2043">Command output streamed normally for another ~3 seconds.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="53:1-53:50;2044-2093">The Codex process (PID 35252) then disappeared.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="54:1-54:141;2094-2234">The rollout ends on the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">exec</code> call itself: no matching tool-call result, no panic, no error, no interrupt, no <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">codex_core::codex: close</code>.</li>
</ul>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="56:1-56:115;2236-2350">Immediately before termination, the logs recorded <strong>20 <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">item/commandExecution/outputDelta</code> events in under 5 ms</strong>.</p>

<h3 dir="ltr" class="text-text-100 mt-2 -mb-1 text-base font-bold" data-sourcepos="58:1-58:54;2352-2405">Reproduction 2 — 12:25:21, after restarting Codex</h3>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="60:1-60:137;2407-2543">Codex emitted another <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">functions.exec</code> call. This one used <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Promise.all</code> to run two nested <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">tools.shell_command</code> calls <strong>concurrently</strong>:</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="65:1-65:208;2647-2854">Both PowerShell processes were spawned successfully. Codex (PID 39540) then disappeared immediately — again with no matching tool result, no panic, no error, no shutdown, no Ctrl+C, and no clean-close event.</p>

<h3 dir="ltr" class="text-text-100 mt-2 -mb-1 text-base font-bold" data-sourcepos="67:1-67:16;2856-2871">Correlation</h3>

</div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="75:1-75:32;3066-3097">Additional supporting evidence:</p>

<ul dir="ltr" class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3 print:block print:space-y-1" data-sourcepos="77:1-80:55;3099-3427">
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="77:1-77:124;3099-3222">Earlier TypeScript errors and missing-file errors were returned normally as tool results and did <strong>not</strong> terminate Codex.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="78:1-78:125;3223-3347">Direct shell tool calls continue to work, including calls producing considerably larger output than the ones that crashed.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="79:1-79:25;3348-3372">The disk was not full.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="80:1-80:55;3373-3427">No orphaned test processes remained after the crash.</li>
</ul>

<h3 dir="ltr" class="text-text-100 mt-2 -mb-1 text-base font-bold" data-sourcepos="82:1-82:14;3429-3442">Ruled out</h3>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="84:1-84:58;3444-3501">No relevant entries were found in the Windows event logs:</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="92:1-92:129;3649-3777">The absence of any WER record is itself notable: this does not look like an ordinary unhandled process fault surfaced to the OS.</p>
</body>
</html>

What steps can reproduce the bug?

1 - Run Codex CLI 0.145.0 on Windows with PowerShell 7, using GPT-5.6 Sol (a code_mode model).
2 - Work in a repository where the test/lint gate chains several commands, e.g. npm run typecheck; node --test <file>; python -m unittest <module>.
3 - Ask Codex to run the full gate, so that it routes the work through a functions.exec call containing nested tools.shell_command invocations.
4 - Observe the process terminate mid-execution, most reliably when the nested calls are long-running, high-output, or launched concurrently via Promise.all.

I do not yet have a minimal deterministic reproducer. The trigger appears to be probabilistic and correlated with output volume and concurrency inside a single exec call rather than with any specific command.

What is the expected behavior?

The code-mode runtime should either return a recoverable tool error to the model, or fall back to the direct shell tool path. Under no circumstances should a failure inside functions.exec terminate the entire Codex process without allowing the TUI to shut down cleanly.

At minimum, the process should emit a diagnosable record — a panic, an error log, or a WER-visible fault — rather than vanishing silently.

Additional information

Relationship to existing issues
#14709 — matches the visible symptom (silent exit back to PowerShell on Windows, leftover TUI text). That issue is now closed without a demonstrated Codex-side fix, and the behaviour is still present in 0.145.0.
#31475 — matches the internal signature more closely: functions.exec crashing the embedded V8 code-mode runtime. That report is on Intel macOS. My case is Windows, which suggests the root cause is in the code-mode runtime itself rather than in platform-specific process handling.

I want to be explicit about the limit of my evidence: I did not obtain a crash dump proving the faulting instruction. The link to #31475 is a hypothesis based on the matching call-site and the matching absence of any tool result, not a demonstrated identity of root cause.

Possibly aggravating factor

~/.codex/logs_2.sqlite on this machine is approximately 1.06 GB and still recording very high-volume TRACE and outputDelta events. This resembles the logging amplification documented in #28224. Given that the first crash was immediately preceded by 20 outputDelta events in under 5 ms, a logging back-pressure interaction cannot be excluded — but it does not appear to be the primary cause, since direct shell calls with larger output do not crash.

Current workaround
Avoid functions.exec entirely and rely on direct shell tool calls.
Or switch to GPT-5.5, which uses the direct tool path rather than code mode.
Artifacts available on request

I have preserved and can provide:

The two rollout JSONL files, including the truncated final exec entries
Extracts from logs_2.sqlite covering both crash windows
The relevant Windows event log entries (or confirmation of their absence)
Process creation/termination records for PIDs 35252 and 39540

View original on GitHub ↗