Sandboxed PowerShell commands intermittently fail on Windows with `windows sandbox: spawn setup refresh`

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #24391
• #24259
• #24050
• #24416

Powered by Codex Action

https://github.com/openai/codex/issues/24391

Sharing a concrete occurrence of the "setup refresh" command actually failing (not just erroring on sandboxed commands), with timestamps, in case it helps narrow down the trigger.

Environment: Windows 11, Codex Store app OpenAI.Codex_26.715.10079.0.

What happened (from .codex\.sandbox\sandbox.<date>.log):

[2026-07-23 22:27:21.098 codex.exe] START: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Command try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch {}
[2026-07-23 22:27:21.629 codex.exe] setup refresh: spawning ...codex-windows-sandbox-setup.exe...
[2026-07-23 22:27:21.701 codex-windows-sandbox-setup.exe] setup binary completed
[2026-07-23 22:27:23.716 codex.exe] FAILURE: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe ...   <- fails after ~2s

[2026-07-23 22:27:43.166 codex.exe] START: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Command ...
[2026-07-23 22:27:43.563 codex.exe] setup refresh: spawning ...codex-windows-sandbox-setup.exe...
[2026-07-23 22:27:43.632 codex-windows-sandbox-setup.exe] setup binary completed
[2026-07-23 22:28:43.942 codex.exe] FAILURE: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe ...   <- this retry HUNG for a full 60s before failing

[2026-07-23 22:30:07.553 codex.exe] START: ...node.exe ... kernel.js --session-id 32e49a78761d4b3f   <- backend restarted
[2026-07-23 22:35:12.120 codex.exe] START: ...node.exe ... kernel.js --session-id 32e49a78761d4b3f   <- same session restarted again 5 min later

User-visible symptom: during the ~60s hang, an actual (non-hidden) powershell.exe console window stayed on screen, overlapping the Codex chat UI — this is presumably the normal behind-the-scenes "setup refresh" powershell invocation becoming visible/foregrounded because it didn't complete quickly like it normally does (every other invocation in the same log, both before and after, completes in well under 1 second). The active chat session's backend (kernel.js) then had to restart twice within a few minutes.

Package status (Get-AppxPackage ... | select Status) was Ok throughout this particular incident — so this looks like a different/lighter failure mode than the Modified, NeedsRemediation package-level corruption I reported over in #17901, but it's the same "setup refresh" mechanism visibly misbehaving. Happy to share the full log excerpt if useful.

Follow-up with a controlled reproduction, since a single occurrence isn't strong evidence on its own — this was tested twice with clean before/after measurements.

Setup: Windows 11, Codex Store app OpenAI.Codex_26.715.10079.0. Measured the backend process CPU time directly via Get-Process <app-server PID>.CPU (the process is codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled).

Trial 1 (fresh app restart, then opened a specific existing task):

• Before opening the task: CPU flat for 30s (+0.02s / 30s ≈ 0.1%)
• ~90s after opening the task: CPU climbing at ~94–98% of one core
• Switched to a different task in the same window: CPU did not drop — kept climbing at ~98% for another 30s
• Only stopped when the whole app (all ChatGPT.exe + the codex.exe app-server process) was killed and restarted

Trial 2 (independent repeat, fresh restart, then reopened the same task):

• Before: flat baseline confirmed again (0 growth over 20s)
• After opening the same task: 5 samples over ~100s → CPU rose monotonically (110.8 → 134.9 → 158.6 → 182.7 → 206.4 accumulated seconds), i.e. sustained ~95%+ of one core the entire time, no sign of settling

The task in question: it was mid-flow, waiting on an external OAuth consent screen (Cloudflare) that had gone stale — by the time it was reopened, the consent link itself returned "authorization failed" in the browser (the backend that originally issued it had been restarted several times since). I can't confirm this staleness is mechanistically why it spins — I looked for corroborating detail in the sandbox log (.codex\.sandbox\sandbox.<date>.log) during both runaway windows and found no relevant entries at all for either occurrence, so whatever loop is running isn't going through the logged "setup refresh" path discussed above.

Summary of what's now confirmed:

• Opening this specific task reliably (2/2) triggers sustained ~95-100% single-core CPU in the app-server process within ~90 seconds.
• The condition does not clear on its own and is not cleared by closing/switching away from the task — only a full app restart stops it.
• Two clean restarts without opening this task stayed idle (~0.1% CPU) for the full observation window, so it's specific to this task, not a general post-restart issue.

Happy to share the task content or further diagnostics if useful.

One more update — I think I've narrowed down the actual trigger, with a clean A/B test.

Hypothesis after the last comment: it's not OAuth/the sandbox refresh mechanism in general, but specifically reopening a task that's holding a stale/expired pending browser-consent flow.

Test A (reproduces the runaway, 2/2): reopened a task that was left mid-flow waiting on a browser OAuth consent screen (Cloudflare, via wrangler login) that had gone stale — the original local callback listener was long gone (the consent link itself no-longer resolved / the redirect came back ERR_CONNECTION_REFUSED when tested). Both times, CPU in the app-server process climbed to ~95-100% of one core within ~90 seconds and did not settle on its own.

Test B (does not reproduce, clean): started a brand-new task, ran wrangler login fresh, and completed the browser consent promptly (within the tool's own callback-listener timeout window, ~2 min). CPU stayed flat (~0.1%) throughout, before, during, and after. Verified the OAuth actually completed successfully (Cloudflare's own "authorization granted" confirmation page, and the CLI reporting a valid logged-in account).

Also worth noting: when I added an instruction telling the agent not to retry wrangler login in a loop if it doesn't complete within ~2 minutes, it followed that correctly (ran it once, waited, then stopped and reported back) — so at least in this environment, the agent's own retry behavior isn't what's spinning the CPU. The runaway seems to live in the app-server/sandbox layer itself, specifically tied to resuming a task that has a dangling/expired OAuth wait state, not to normal wrangler login usage in general.

Not a fix, just hopefully a tighter repro condition than before.