Windows Desktop crash when write_stdin interrupt hits unsupported unified exec backend

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

OpenAI.Codex 26.623.11225.0 (OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0)

Related local CLI version on the same machine: codex-cli 0.142.3.

What subscription do you have?

Not included in this public report.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop crashed after a model-issued write_stdin/interrupt attempt against a unified exec process backend that reported interrupts are unsupported.

The visible crash banner was:

An error has occurred
Codex crashed with the following error:

  (code=3221225786, signal=null).
Most recent error: {"timestamp":"2026-07-01T17:04:26.840097Z","level":"ERROR","fields":{"error":"write_stdin failed: Unified exec process failed: process interrupt is not supported by this process backend"},"target":"codex_core::tools::router"}

This looks adjacent to write_stdin lifecycle and interrupt handling, but the exact failure mode is different from #18494. In #18494 the maintainer explanation was a non-tty or stale-session stdin write. Here the reported error is that the unified exec process backend itself does not support process interrupts, and the failure surfaced as a fatal Codex Desktop crash with Windows code 3221225786.

What steps can reproduce the bug?

I do not yet have a standalone deterministic reproducer, but the observed shape was:

1. Use Codex Desktop on Windows in a long-running coding thread with shell tool calls.
2. Start or have Codex manage a command through unified exec.
3. During stall/recovery handling, Codex attempts to interrupt the tool session through write_stdin rather than waiting for completion or using a backend-supported cancellation path.
4. The backend reports: process interrupt is not supported by this process backend.
5. Codex Desktop shows the crash banner above and the active turn is lost.

A useful focused regression would be a unified-exec backend/session fixture whose interrupt capability is false or unsupported, followed by a model/tool request equivalent to write_stdin with Ctrl-C or another interrupt payload. The expected result should be a non-fatal, capability-gated tool error or no-op, not a desktop crash.

What is the expected behavior?

If a unified exec session/backend cannot support process interrupts, Codex should handle that capability boundary before dispatching an interrupt attempt, or downgrade it to a recoverable tool result. In particular:

• write_stdin should not be used as a generic interrupt mechanism unless the target session/backend advertises that it is live and interrupt-capable.
• An unsupported interrupt should not be logged through the router as a fatal desktop crash.
• The model should receive a clear recoverable result so it can switch to polling, bounded timeout, or an explicit cleanup path.
• The current thread/turn should remain usable after the failed interrupt attempt.

Additional information

I searched before filing. Closest related issues found:

• #18494: closed; covers stale/non-tty write_stdin stdin liveness, not this unsupported-interrupt backend error.
• #16384: open; covers Windows write_stdin polling crash under concurrent parent/sub-agent polling, but does not include this exact unsupported backend interrupt error.
• #24518: open; covers broader interrupt failure/context loss, but not the unified exec write_stdin backend capability failure.

Downstream mitigation in my project was to add local agent guidance and crash classification that forbids Ctrl-C/control-byte write_stdin interruption for long-running commands and routes recovery through bounded commands, proof queues, and custody-aware process cleanup. That avoids self-triggering this class locally, but it does not fix the upstream Codex Desktop crash path.