Windows sandbox 0.146.0: read-only command times out without output; child observed suspended

Summary
A native Windows Codex 0.146.0 read-only inspection timed out without useful output. In a separate model-free sandbox diagnostic, the PowerShell child was later observed with one thread in Wait/Suspended and zero CPU. The component responsible for suspension is unknown.

Environment, recorded during the incident

• Codex CLI: 0.146.0, native Windows x64 installation.
• Windows kernel release reported by Node: 10.0.26200. An older .NET helper returned a compatibility-shim version; that value is not used as the OS version.
• Node: 24.12.0. Windows PowerShell: 5.1.26100.9168.
• Existing ChatGPT authentication returned CHATGPT_SESSION_VALID, exit 0, at 2026-09-09 01:45:01 UTC.
• Existing model: gpt-5.6-terra. No model changes.
• Coordinator approval policy: never; command sandbox: read-only; allow_login_shell=false.
• Existing Windows sandbox configuration: elevated. This is the sandbox implementation name; the user did not elevate the diagnostic process. A prior successful sandboxed inspection reported a separate non-administrator sandbox account.

Two distinct observations

1. Native coordinator run, 2026-09-09 approximately 01:14 UTC: its initial inspection returned code 124 with no useful output. It stopped before creating any child agents. Codex itself exited 0; the custom launcher exited 74 and its verifier 33 because the task was incomplete. Those last two are our wrapper codes, not upstream Codex errors.
2. Separate model-free sandbox diagnostic, approximately 01:57-02:01 UTC: the controller recorded ETIMEDOUT after 15030 ms, process exit_code=null, empty stdout and stderr, and neither initial marker was reached. A subsequent bounded observation found its PowerShell child with one thread in Wait/Suspended and zero CPU. This diagnostic did not return a normal exit code 124 and did not invoke a model.

The inspected command was intended only to print markers, check non-administrator identity, and invoke Node with restricted read permissions to read six fixed instruction/skill files. Its source was inspected before use. A simplified command passed the installed PowerShell parser, but its sandbox execution still timed out. Syntax success is not presented as execution success.

Historical comparison
A previous native run on the same setup created two actual child agents, recovered their results and passed 12 synthetic JavaScript tests. That run had a separate custom-supervisor cleanup problem, subsequently addressed in isolated tests. We have not demonstrated agent work plus correct closure in one subsequent complete run.

Security software and diagnosis limits
RAV Endpoint Protection displayed PowerShell detections named Suspicious.Process.PDO.OCL / PDO.PSD. The device owner identifies these as the assistant's authorized development work. We have not tied a particular event to the observed suspended PID or established that RAV caused the suspension. We have not disabled protection, approved broad exclusions or resumed suspended threads.

The documented sandbox log exists. A read-only sample of its last 120 lines did not provide a record correlated to the September incident's owned PIDs or time window. Date references in that sample were from April; we do not treat them as evidence for this incident. The raw log is not attached.

Request

1. Is this specific no-output/suspended-child symptom known for the Windows runner in 0.146.0?
2. What bounded, read-only observation would distinguish a runner startup/pipe problem, sandbox-user policy failure and endpoint-protection intervention, without a new model run, elevation or changing security controls?
3. Where should this version record command-runner diagnostics if the documented sandbox.log sample cannot be correlated to the incident?
4. Is there a version-specific documented fix that preserves the existing sandbox? We would review it before any update or execution.

This is a report from preserved observations, not a freshly reproduced case. No repository contents, account identifiers, device name, home paths, session transcripts, credentials, quarantine files or databases are attached. Full evidence is retained locally; any additional sharing would be reviewed separately.

Start by locating the Windows runner and command-runner diagnostic paths, then inspect the documented sandbox.log around the preserved incident window and owned PIDs. Compare the available evidence for runner startup or pipe failure, sandbox-user policy failure, and endpoint-protection intervention without changing security controls or running a model. Done means a bounded diagnostic procedure and any version-specific fix are identified or the missing instrumentation is documented.