Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   performance

   on Jul 17, 2026
2. github-actions commented on Jul 17, 2026

   

   github-actionsBot

   on Jul 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows elevated sandbox fails with "helper_unknown_error", while unelevated works #32855

   Powered by Codex Action
3. weijunswj commented on Jul 23, 2026

   

   weijunswj

   on Jul 23, 2026

   More actions

   Additional Windows observation showing the sandbox/Full Access differential:

   • Codex/ChatGPT desktop: 26.715.10079.0
   • Windows 11 Home 25H2, build 26200.8894, x64
   • In workspace-write sandbox mode, ordinary process/system queries such as Get-Process and tasklist repeatedly remained stuck and had to be terminated.
   • The same read-only diagnostics completed normally in Full Access/out-of-sandbox mode, generally within a few seconds.
   • Simple shell output still worked in sandbox mode, so the failure was concentrated around process/system inspection rather than every command.
   • Retrying sandboxed diagnostics was stopped to avoid accumulating leaked setup helpers.
   • At the time of the final process check, the count of codex-windows-sandbox-setup.exe was 0. This occurrence therefore confirms the hang and Full Access workaround, but not a persistent helper leak in that particular sample.

   The practical workaround remains switching affected tasks to Full Access/no-sandbox and avoiding repeated sandbox retries. Full Access is only appropriate for trusted workspaces.
4. JalenBuildsHub commented on Aug 9, 2026

   

   JalenBuildsHub

   on Aug 9, 2026

   More actions

   Additional reproduction: App-session write-root accumulation predicts leaked Windows sandbox helpers

   I can reproduce the helper leak described here on a newer Codex App and CLI. The newer evidence
   suggests that the elevated sandbox symptom is driven by the write-root payload growing inside a
   long-lived App session, rather than by PowerShell or the workspace alone.

   Environment

   • Codex App: 26.803.5235.0 (OpenAI.Codex, Microsoft Store package)
   • Codex CLI: 0.147.0
   • Windows: Windows 11 x64, build 10.0.26200
   • Native Windows workspace, not WSL
   • Elevated Windows sandbox through a named permissions profile
   • Hooks disabled during this reproduction

   New reproduction evidence

   The App process started after the local permissions profile had been narrowed, so this was not a
   stale pre-fix App process. By 22:40 local time, 38
   codex-windows-sandbox-setup.exe processes were present; 31 were children of the live bundled App
   codex.exe process.

   Two setup attempts from the same packaged App directory occurred within one second:

   Attempt	Helper payload length	Result
   21:42:02.206	7,988 bytes	Completed; log reached processed 1 write roots and setup binary completed
   21:42:02.578	10,720 bytes	Stalled after the ACL-read phase; never logged setup binary completed

   The payload emitted by the same long-lived App parent grew monotonically:

   7,628 -> 9,964 -> 10,664 -> 10,832 bytes
   

   Stalls began when the payload crossed roughly 9.9 KB. In the day-long sample, payloads at or below
   8,116 bytes normally completed, while payloads at or above 9,956 bytes stalled. This is an observed
   boundary on one machine, not a proposed universal threshold.

   The native CLI reading the same effective config emitted 2,512-2,708-byte payloads with 6-7 write
   roots and completed sandbox refresh in roughly 30 ms. Multiple repo-rooted CLI tool runs completed
   without leaking a helper.

   At 23:04, before a separate blind-agent comparison, 16 setup helpers were already present. The count
   remained 16 across three read-only child probes. At 23:14 all 16 were CPU-active during a two-second
   sample; 12 were parented to the live App process, four had no live parent, and their combined working
   set was about 291.5 MB. The child probes completed and left no processes, so they did not create or
   worsen this backlog.

   Why this looks App-specific

   • The accumulating helpers use the sandbox binary bundled with the Store App.
   • Most leaking helpers are direct children of the App's bundled codex.exe / app-server.
   • A fresh App session starts with smaller payloads and works, then degrades as its per-session
     payload grows.
   • Repo-rooted native CLI sessions using the same profile remain small and complete normally.
   • Narrowing a previously broad local write grant reduced the initial payload but did not prevent
     the App-session payload from growing again.

   The process working directory itself is not the differentiator: the same App directory produced
   both the completed and stalled attempts above. Earlier home-rooted launches worsened the payload,
   but they were a proxy for a larger write-root set, not the complete cause.

   Expected behavior

   1. The App should rebuild or deduplicate the effective write-root set instead of accumulating roots
      across a long-lived session.
   2. One tool request should not leave a CPU-spinning setup helper after the parent times out.
   3. Setup refresh should be single-flight per App parent, with orphan cleanup on timeout.
   4. If the root set is too large, Codex should fail promptly with the root count/payload size and an
      actionable message rather than spawning another helper.
   5. App acceptance should include a long-session accumulation test, not only a per-attempt completion
      ratio.

   Suggested regression test

   • Keep one Codex App process open.
   • Exercise 50-100 tool calls across several exact repo workspaces.
   • Assert that the effective write-root count and serialized payload do not grow monotonically after
     a workspace is released.
   • Assert that every setup helper exits within a bounded interval and that the live helper count
     returns to zero.
   • Repeat with a named permissions profile containing :workspace_roots plus several explicit repo
     grants.

   Sanitized sandbox-log excerpts and a payload/root-count timeline can be supplied if helpful.