Windows: corrupted workspace dependency bundle halts all shell execution; Diagnose reports "healthy" and app reinstall does not fix

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

OpenAI.Codex_26.721.4979.0 (MSIX / WindowsApps desktop app), codex-command-runner-0.146.0-alpha.3.1, VS Code extension: openai.chatgpt-26.721.41059

What subscription do you have?

Pro Max 20x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex desktop (Windows): corrupted workspace dependency bundle halts all shell command execution; Diagnose reports "healthy"

Summary

The Codex desktop app on Windows stopped dispatching shell commands entirely for ~12.5 hours. Any
command, including Get-Date, hung forever. The app wrote a START line to its sandbox log and then
never spawned a process to execute the command. The UI became unresponsive.

Root cause: a corrupted workspace dependency bundle (Settings → Workspace Dependencies → the
bundled Node.js and Python tools).

Fix: Settings → Workspace Dependencies → Reset and Install Workspace. ~2 minutes. The next
command ran in 416 ms.

Two defects are worth your attention:

1. Diagnose reported "healthy" minutes before the fix, while the bundle was corrupt enough that

no shell command could run at all.

1. A full uninstall and reinstall of the app did not fix it, because the bundle persists outside

the application.

Together these two turned a two-minute fix into a 12-hour outage.

---

Environment

• Windows 11 Pro 10.0.26200, 32 GB RAM, NTFS, ~280 GB free C:, ~1.8 TB free D:
• Codex desktop OpenAI.Codex_26.721.4979.0 (MSIX / WindowsApps)
• codex-command-runner-0.146.0-alpha.3.1
• VS Code extension openai.chatgpt-26.721.41059
• Windows Defender only, no third-party AV
• Virtualization-Based Security running: VirtualizationBasedSecurityStatus = 2,

HVCI / Memory Integrity Enabled = 1, SecurityServicesRunning = 2,3,4,5

Duration

~1day 12 hours 25 minutes.

• Last successful command: 2026-07-27 23:33:25
• First hang: 2026-07-27 23:41:53
• Resolved: 2026-07-28 11:35:08

Impact: this machine runs a multi-lane agentic development workflow with ~20 concurrent work streams
using Codex as the controller runtime. All stalled for the duration.

Failure signature

While hung:

[2026-07-28 11:24:01.664 codex.exe] START: ...powershell.exe -Command try { [Console]::OutputEncoding=... } catch {}
Get-Date
<nothing further, indefinitely>

Verified at the OS level during the hang:

• No codex-windows-sandbox-setup.exe process existed
• No codex-command-runner*.exe process existed
• codex.exe sat at 38% of one core across 45 threads — a busy-wait, not an idle network wait

After the bundle reinstall:

[2026-07-28 11:35:08.055 codex.exe] START:   ... Get-Date
[2026-07-28 11:35:08.471 codex.exe] SUCCESS: ... Get-Date        # 416 ms

---

Defect 1: Diagnose false negative (highest value)

Minutes before resolution, Settings → Workspace Dependencies → Diagnose reported healthy. The
bundle was in fact corrupt enough that no shell command could execute.

Diagnose was the one tool pointing directly at the actual fault, and it cleared it. Had it reported
the bundle as bad, this would have been a two-minute fix instead of a 12-hour outage.

Suggested: have Diagnose actually validate bundle integrity and executability, not just presence.

Defect 2: App reinstall cannot replace the bundle

A full uninstall and reinstall of the Codex desktop app did not resolve this, because the
workspace dependency bundle persists outside the application.

This defeats the universal user instinct that reinstalling an app replaces anything corrupt within
it. Users will spend hours on reinstall cycles that cannot possibly work.

Suggested: have the installer validate or replace the bundle, and/or have Diagnose state
explicitly that reinstalling the app will not fix bundle corruption and to use Reset and Install
Workspace.

---

Full diagnostic chronology

Included to show how far a user is driven from the actual fault when Diagnose reports healthy.

Phase 1 — first response

| Step | Result |
|---|---|
| 3 full machine reboots | no change |
| Repeated Codex desktop app restarts | no change |
| Codex app "repair" option | no change |

Phase 2 — system resources

| Step | Result |
|---|---|
| RAM: 31.7 GB total, 11 GB free | memory exhaustion eliminated |
| Disk: 280 GB free C:, 1.75 TB free D: | disk exhaustion eliminated |
| Counters: PhysicalDisk 87% busy, CPU 7.5% | I/O bound, not compute bound |
| 7,661 × hide users: failed to hide C:\Users\Default ... Access is denied | benign, present during successful commands |
| 103 × junction: failed to create ... Access is denied | benign, same family |

Phase 3 — git worktree cleanup — did NOT fix it

Initially attributed the disk load to accumulated git worktrees inside the sandbox write root.

| Step | Result |
|---|---|
| Project worktree tree measured: 62 dirs, 380,631 files, 73.2 GB (enumeration alone took 415 s) | genuinely oversized |
| Codex-managed worktree root: 146 dirs, 60,673 files, 13.9 GB, only 7 git-registered | 139 orphaned |
| Verified all 60 registered worktrees for uncommitted work | 47 clean, 12 dirty, 1 missing |
| Removed 46 clean worktrees + git worktree prune | 51 GB reclaimed |
| Retested | still hung |

Phase 4 — sandbox setup deadlock — did NOT fix it

| Step | Result |
|---|---|
| Found codex-windows-sandbox-setup.exe hanging, never logging setup binary completed | reproducible |
| Observed it stuck at 0.1% disk I/O | blocked, not working |
| Killed the stuck process manually | pending command completed instantly |
| Added a watchdog to auto-kill setup processes older than 20 s, then 5 s | worked briefly |
| Watchdog later logged gone=False repeatedly over 80+ s | process became unkillable even with force |

Reproducible signature by payload at this stage:

| payload_len | write roots | outcome |
|---|---|---|
| 8584 | processed 0 write roots (read roots delegated) | setup binary completed in 40 ms |
| 8840 / 9100 | granting write ACE to <path> | deadlocked, never exited |

Phase 5 — configuration elimination — did NOT fix it

| Step | Result |
|---|---|
| sandbox_mode workspace-write → danger-full-access; [windows] sandbox elevated → unelevated | setup binary removed from path; still hung |
| Removed approvals_reviewer = "auto_review" | still hung |
| approval_policy on-request → never | still hung |
| Uninstalled the VS Code extension | still hung |
| Full uninstall + reinstall of the desktop app | still hung |
| powershell.exe -Command "Get-Date" run directly, outside Codex | 0.21 s, healthy |
| Confirmed no PowerShell profile files exist | profile hooks eliminated |
| Confirmed Defender only, no third-party AV | AV interference eliminated |
| Retested on an idle machine after a fresh boot: 0% disk, 7% CPU, 12 GB free RAM | still hung |

Phase 6 — resolution

| Step | Result |
|---|---|
| Settings → Workspace Dependencies → Diagnose | reported "healthy" (false negative) |
| Settings → Workspace Dependencies → Reset and Install Workspace | ~2 minutes |
| Fresh session, Get-Date | SUCCESS in 416 ms |

---

Secondary observations

The Phase 4 sandbox-setup deadlock may share this root cause. It became unreachable once
sandbox = "unelevated" removed the setup binary from the path, yet commands still hung, suggesting
it was a downstream effect rather than an independent bug. Two details still seem worth checking:

• The stuck process became unkillable by a forced terminate across 80+ seconds, implying an

uninterruptible kernel wait. With HVCI enabled, a virtualization-based-security interaction is
worth ruling out.

• The last healthy run logged codex.exe --codex-run-as-fs-helper and

read ACL helper already running; skipping spawn. After failures began, no fs-helper spawn
appears anywhere in the log. If the write-root path waits on that helper while stale state claims
it is alive, it would wait forever.

Codex relaunches the ChatGPT desktop app on startup. Opening Codex took ChatGPT from 0 processes
to 4, consuming ~2.5 GB and roughly two CPU cores. This made it appear that Codex itself was
saturating the machine and contributed to a false diagnostic path. Users who close ChatGPT to free
resources will find it silently restarted by Codex.

Questions

1. What conditions corrupt the workspace dependency bundle, and can Diagnose be made to detect it?
2. Can the installer validate or replace the bundle, given that a reinstall currently cannot?
3. Is the codex-windows-sandbox-setup.exe write-ACE deadlock known, and is HVCI implicated?
4. Is there verbose dispatch-level logging beyond the sandbox log?

Attachments available on request

• Full sandbox log, 12 MB, covering both failure modes and the recovery
• Process snapshot captured during a hang
• Sanitized config.toml

What steps can reproduce the bug?

NOTE: session id / token limit / context window are not applicable. This is a process-dispatch
failure, not a model interaction. No model call is involved. The app never spawns the process.

The event that corrupts the workspace dependency bundle is unknown. Once in the corrupted state
the failure is 100% deterministic and survives reboots, app restarts, and full reinstalls.

To confirm you are in this state:

1. Open Codex on Windows with any project.
2. Ask it to run a trivial shell command, e.g. Get-Date.
3. The command hangs indefinitely. The UI eventually becomes unresponsive.
4. Check ~/.codex/.sandbox/sandbox.<date>.log. You will see a START line with no SUCCESS or

FAILURE following it:

[2026-07-28 11:24:01.664 codex.exe] START: ...powershell.exe -Command try { [Console]::OutputEncoding=... } catch {}
Get-Date
<nothing further, indefinitely>

1. While it hangs, check running processes. Critically, NOTHING is spawned:

• no codex-windows-sandbox-setup.exe
• no codex-command-runner*.exe
• codex.exe sits at ~38% of one core across ~45 threads (a busy-wait)

1. Confirm the shell itself is healthy by running the same command outside Codex:

powershell.exe -Command "Get-Date" -> returns in ~0.21s

1. Settings > Workspace Dependencies > Diagnose -> reports "healthy" (this is the false negative)

1. Settings > Workspace Dependencies > Reset and Install Workspace -> ~2 minutes

Open a fresh session, run Get-Date -> SUCCESS in 416 ms

A full uninstall and reinstall of the app at step 7 does NOT fix it, because the bundle persists
outside the application.

What is the expected behavior?

Three things:

1. The shell command should execute and return. Instead the app logs START and never spawns a

process, hanging forever with no error, no timeout, and no user-facing indication of what failed.

1. Diagnose should detect a corrupted workspace dependency bundle. It reported "healthy" while the

bundle was broken badly enough that no shell command could execute at all. Diagnose was the one
tool pointing at the actual fault and it cleared it. It should validate bundle integrity and
executability, not just presence.

1. Uninstalling and reinstalling the app should repair or replace the bundle, or the UI should state

explicitly that it will not. Reinstalling is the universal user instinct for "replace anything
corrupt," and here it cannot work because the bundle lives outside the app.

Failing all of that, a dispatch timeout with a clear error would have turned a 12-hour outage into
a 30-second one.

Additional information

DURATION: ~1 day 12 hours 25 minutes. Last success 2026-07-27 23:33:25, resolved 2026-07-28 11:35:08.
Impact: a multi-lane agentic dev workflow with ~20 concurrent work streams using Codex as the
controller runtime, fully stalled for the duration.

ELIMINATED BEFORE FINDING THE CAUSE (each tested, symptom unchanged) - listed because it shows how
far the Diagnose false negative drives a user from the real fault:

• 3 full reboots; repeated app restarts; the app "repair" option
• Full uninstall + reinstall of the desktop app
• Uninstalled the VS Code extension (openai.chatgpt-26.721.41059)
• approval_policy: on-request -> never
• Removed approvals_reviewer = "auto_review"
• sandbox_mode: workspace-write -> danger-full-access; [windows] sandbox: elevated -> unelevated
• Removed 46 stale git worktrees, reclaimed 51 GB (project tree was 380,631 files / 73.2 GB)
• Verified no PowerShell profile files exist; Windows Defender only, no third-party AV
• Retested on a freshly booted idle machine: 0% disk, 7% CPU, 12 GB free RAM -> still hung

SECONDARY DEFECT, possibly the same root cause:
While [windows] sandbox = "elevated", codex-windows-sandbox-setup.exe would deadlock and never exit:

setup refresh: spawning ...codex-windows-sandbox-setup.exe (payload_len=8840)
granting write ACE to <path> for sandbox group and capability SID
read-acl-only mode: applying read ACLs
read ACL run completed
<never logs "setup binary completed", never exits>

Reproducible signature by payload:
payload_len=8584, "processed 0 write roots (read roots delegated)" -> completes in 40 ms
payload_len=8840/9100, "granting write ACE to <path>" -> deadlocks forever

Notable:

• Stuck at 0.1% disk I/O. Blocked, not working.
• Killing the stuck process made the pending command complete instantly

(logged: setup refresh: exited with status ExitStatus(4294967295)). Reproduced several times.

• Later instances became UNKILLABLE: forced terminate returned but the process survived repeated

attempts over 80+ seconds, implying an uninterruptible kernel wait. HVCI / Memory Integrity is
enabled on this machine (VirtualizationBasedSecurityStatus=2, SecurityServicesRunning=2,3,4,5),
so a virtualization-based-security interaction may be worth ruling out.

• The last healthy run logged "codex.exe --codex-run-as-fs-helper" and "read ACL helper already

running; skipping spawn". After failures began, no fs-helper spawn appears anywhere in the log.

UNRELATED BUT WORTH KNOWING:
Codex relaunches the ChatGPT desktop app on startup. Opening Codex took ChatGPT from 0 processes to
4, consuming ~2.5 GB and roughly two CPU cores. This made it appear Codex itself was saturating the
machine and contributed to a false diagnostic path. Users who close ChatGPT to free resources will
find it silently restarted.

ATTACHMENTS AVAILABLE ON REQUEST: full 12 MB sandbox log covering both failure modes and the
recovery; process snapshot captured during a hang; sanitized config.toml. Not attached here because
the log contains user paths throughout.