[Bug]: Windows long-running Codex tool loses exec cell and completion

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

On Windows with the Codex provider:

1. Open a T3 Code thread and ask Codex to run a foreground command that lasts longer than the functions.exec yield window. A deterministic example is a pytest suite lasting 1-2 minutes.
2. Codex calls functions.exec, which calls shell_command. The cell yields with Script running with cell ID <id>.
3. Codex calls functions.wait with that cell ID until completion.
4. Observe that T3/Codex can discard the cell before the final result is delivered: a later wait returns exec cell <id> not found even though the child process may still be running or may already have finished.
5. Separately, run a 5-15 second foreground nested tool call. While it is in flight, the transcript can show only the assistant's preceding status text with no visible command/tool row. Sending a follow-up message then steers the turn and the tool result is returned to the agent only as aborted, with no final child exit status.

The failure reproduced repeatedly in one thread. A full pytest run yielded normally, two waits succeeded, and the next wait lost the cell. Detached Start-Process and WMI-launched descendants also failed to leave a dependable terminal result after the provider/harness lifecycle intervened.

Expected behavior

• A yielded exec cell remains addressable until its command reaches a terminal state and the final exit code/output has been acknowledged.
• T3 visibly shows an in-flight foreground tool call.
• A steered follow-up either leaves the command attached and queryable, or explicitly cancels it and reports the child process's terminal state.
• After an app/thread interruption, the provider can reattach using a durable job ID and recover the final result. This must be reliable enough for unattended builds, test suites, CI watches, and deployments.

Actual behavior

The execution handle disappears while work is still ambiguous. The agent receives exec cell <id> not found or aborted instead of the final command result. The UI may look idle while the tool is in flight. This makes it impossible to know safely whether an overnight task completed, failed, or is still running, and can cause duplicate reruns.

This overlaps the in-flight visibility symptom in #5043, but adds a separate lifecycle/data-loss failure: the resumable cell and final exit status are lost.

Impact

Major degradation or frequent failure

Version or commit

T3 Code v0.0.33 (Alpha); Codex CLI 0.147.0; bundled command runner observed as 0.146.0-alpha.9.2

Environment

Windows 11 Pro 64-bit, version 10.0.26200 (build 26200); T3 Code desktop; Codex provider; PowerShell; full-access workspace

Logs or stack traces

functions.exec -> Script running with cell ID 16
functions.wait(cell_id=16) -> additional output / still running
functions.wait(cell_id=16) -> exec cell 16 not found

# Separate short foreground calls after a follow-up message was sent:
functions.exec -> aborted

The provider event log is under .t3/userdata/logs/provider/ and records the affected thread/turn. No application secrets are required for the repro.

Screenshots, recordings, or supporting files

The transcript visibly shows the status message but no in-flight tool row while the command is pending. This matches part of #5043's presentation symptom.

Workaround

No reliable in-app workaround. Short foreground shards can avoid yielding, but that does not help genuinely long jobs. We are testing an OS-scheduled runner that writes a durable manifest (queued/running/completed/failed), heartbeat, PID, stdout/stderr, JUnit, and exit-code marker so a later turn can reattach without relying on the T3 exec-cell handle. GitHub Actions is the safer current option for repository test/deploy jobs because its run ID and terminal conclusion remain queryable.

Related upstream Codex report: https://github.com/openai/codex/issues/38069#issuecomment-5299034507

Start in apps/desktop and reproduce the Windows Codex flow with a foreground command that outlasts the functions.exec yield window. Inspect the affected thread and turn records under .t3/userdata/logs/provider/ while tracing the exec and wait lifecycle. Done means the cell remains queryable through terminal completion, the in-flight tool is visible, and the final exit state can be recovered after interruption.