Skip to content

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

Open
Open
Sandboxed PowerShell commands intermittently fail on Windows with windows sandbox: spawn setup refresh#25497
Labels
bugSomething isn't workingextensionIssues related to the VS Code extensionsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

Description

@Yong-yuan-X
Yong-yuan-X
opened on Jun 1, 2026

What version of the IDE extension are you using?

openai.chatgpt@26.527.31454

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code 1.122.1

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Sandboxed shell commands frequently fail immediately on Windows before the command itself runs.

The repeated error is:

execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })

This happened with simple read-only PowerShell commands in a workspace on E:\..., including:

Get-ChildItem -Force

It also happened with search commands such as:

rg -n "score|评分|fallback|兜底|short|truncate|limit|85|90|75|rank|排序" -S .

In one session, both commands failed when run through the sandbox. Retrying Get-ChildItem -Force outside the sandbox with escalation succeeded immediately.

The same sandbox startup error also occurred when trying to query local tool versions:

code --version
code --list-extensions --show-versions

Both failed inside the sandbox with windows sandbox: spawn setup refresh, then succeeded when rerun outside the sandbox with approval.

This makes normal repo inspection unreliable because even basic read-only commands fail during sandbox setup.

What steps can reproduce the bug?

  1. Use the Codex/OpenAI IDE extension in VS Code on Windows.
  2. Open a workspace on a Windows drive, for example an E:\... repo.
  3. Start a Codex session with filesystem sandboxing enabled, e.g. workspace-write.
  4. Ask Codex to inspect the repo or run a simple read-only command.
  5. Codex attempts a sandboxed PowerShell command such as:
Get-ChildItem -Force
  1. The command fails immediately with:
execution error: Io(Custom { kind: Other, error: "windows sandbox: spawn setup refresh" })
  1. Rerun the same command outside the sandbox with escalation/approval.
  2. The command succeeds.

Expected behavior:

Sandboxed read-only PowerShell commands should run normally, or sandbox startup failures should provide a more actionable diagnostic.

Actual behavior:

The sandbox fails during startup/setup with windows sandbox: spawn setup refresh, blocking even basic read-only commands.

What is the expected behavior?

No response

Additional information

No response

Activity

  1. Yong-yuan-X
    added
    extensionIssues related to the VS Code extension
    on Jun 1, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    tool-callsIssues related to tool calling
    on Jun 1, 2026

  3. github-actions commented on Jun 1, 2026

    @github-actions
    github-actionsBot
    on Jun 1, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. BaseBlank commented on Jun 10, 2026

    @BaseBlank
    BaseBlank
    on Jun 10, 2026

    #24391

  5. happycrelab-web commented on Jul 23, 2026

    @happycrelab-web
    happycrelab-web
    on Jul 23, 2026

    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.

  6. happycrelab-web commented on Jul 23, 2026

    @happycrelab-web
    happycrelab-web
    on Jul 23, 2026

    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.

  7. happycrelab-web commented on Jul 23, 2026

    @happycrelab-web
    happycrelab-web
    on Jul 23, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingextensionIssues related to the VS Code extensionsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions