[Windows][CLI 0.144.3] Codex silently exits while waiting on a tool after successful auto-compaction / PostToolUse activity

What version of Codex CLI is running?

codex-cli 0.144.3, installed globally with npm.

Note: 0.144.4 was installed after these incidents. Its release notes say there are no user-facing changes, and I have not repeated the destructive workload on 0.144.4 yet.

What subscription do you have?

Pro

Which model were you using?

gpt-5.6-sol with xhigh reasoning.

What platform is your computer?

Windows 11 Pro x64, build 26100.7171
PowerShell 5.1.26100.7019
Node.js v24.11.1

What terminal emulator and version are you using?

Windows console host / Windows PowerShell 5.1, interactive Codex TUI started from a dedicated visible PowerShell window with --no-alt-screen.

Codex doctor report

Not available. codex doctor --json did not produce a JSON report in the installed CLI.

What issue are you seeing?

During long-running autonomous CLI Goals, codex.exe terminates without a final message or diagnostic record.

The parent PowerShell remains open, but both the native Codex process and npm Node wrapper disappear. The rollout ends in the middle of a tool wait. There is no panic, fatal, turn_aborted, Goal completion event, or matching Windows Error Reporting/Application Error event for Codex, Node, or PowerShell.

This happened on multiple recovery attempts:

1. A resumed, high-context session ended while polling a running shell tool.
2. A fresh session with a reduced MCP/app surface and an early auto-compaction threshold also ended while waiting on a shell tool.

The fresh run is the important case because auto-compaction completed successfully first. The active context dropped to about 19k tokens and was only 26,889 tokens immediately before termination. One focused test completed successfully (5 passed in 0.24s). A second shell test started, emitted 15 passing dots, and the final visible TUI status became:

Running 5 PostToolUse hooks

The process then disappeared and the console returned directly to the PowerShell prompt. The launcher's post-exit diagnostic statements did not run.

A user-level command hook was enabled for PostToolUse. Only one PostToolUse command definition exists; "5 hooks" therefore appears to be concurrent/pending hook activity, not five separate configurations. The hook is correlated with the failure but is not proven to be the root cause.

What steps can reproduce the bug?

The workload is not yet a minimal deterministic reproducer, but the controlled recovery scenario was:

1. On Windows, enable command hooks for lifecycle events including PreToolUse and PostToolUse.
2. Launch an interactive CLI Goal from PowerShell with a reduced configuration:

codex -C <workspace> --no-alt-screen --disable apps `
  -c model_auto_compact_token_limit=160000 `
  -c model_auto_compact_token_limit_scope=total `
  -c mcp_servers.<unrelated-server>.enabled=false `
  "<long autonomous task>"

1. Let the Goal use three subagents and overlapping shell-tool calls.
2. On the root agent, run a test/tool command that exceeds the initial tool yield and launches ordinary PowerShell subprocesses.
3. Let Codex poll/wait for the running tool while subagent tool calls complete.
4. Observe the TUI reach Running 5 PostToolUse hooks, then return directly to PowerShell with no final rollout event.

Sanitized hook configuration:

{
  "hooks": {
    "PostToolUse": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "<node> <third-party-hook.js>",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

The active unit tests that could invoke WMI/detached-process behavior were explicitly skipped. The executed code used ordinary PowerShell subprocesses.

What is the expected behavior?

Codex should remain alive until the tool and hooks finish.

If a tool, hook, subprocess, compaction step, or process-group operation fails, Codex should:

• record the failing component, exit code, timeout, stderr, and termination reason;
• isolate hook cancellation/failure from the parent CLI process;
• preserve the tool as a recoverable pending/unknown state;
• emit a terminal failure/aborted event instead of silently ending;
• allow an active Goal to reattach without leaving ambiguous partial state.

Additional information

Confirmed:

• Early auto-compaction worked in the fresh session.
• Context exhaustion cannot explain the fresh post-compaction termination by itself.
• The rollout ended during the long tool wait without a matching result.
• codex.exe and the Node wrapper disappeared while the launcher PowerShell remained.
• No matching WER/Application Error, Resource Exhaustion event, panic, or fatal log exists.
• No pytest/build process remained afterward.
• Disabling hooks for a single invocation is accepted and leaves Goals, MCP, and multi-agent features available.

Hypotheses, not confirmed root causes:

• A Windows race/unhandled exit path involving hook fan-out, long-running tool polling, and child process/job/console-control handling.
• The console behavior is compatible with a control-event interruption, but no exit code or dump was produced, so STATUS_CONTROL_C_EXIT is not claimed as confirmed.

Impact:

This repeatedly interrupts multi-hour autonomous tasks, leaves a dirty working tree and durable Goal ledger partially advanced, and requires manual fencing/reconciliation before safe continuation.

Related but not duplicate:

• #18067: large hook payloads fail silently on Linux/Windows.
• #21753: hook parity tracker notes incomplete PostToolUse, subagent, compaction, and cross-surface behavior.

I can provide sanitized rollout excerpts, exact timestamps, process-tree snapshots, Windows event exports, and session IDs privately to OpenAI maintainers. The complete rollout is not attached publicly because it contains proprietary repository paths, prompts, and source context.