Windows elevated sandbox repeatedly scans pnpm node_modules, causing 100% disk usage and 30–130s tool latency #33737

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.

   • Native Windows sandbox setup scales poorly with writable-root size, making apply_patch take 45–55 seconds #33158
   • Extremely Slow — ACL before every command, 20-30s each time #33365
   • Windows Desktop elevated sandbox hangs after ACL setup and leaks setup helpers; unelevated works (0.145.0-alpha.18) #33732

   Powered by Codex Action
3. genusJoe commented on Jul 21, 2026

   

   genusJoe

   on Jul 21, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming this on a newer Windows build with additional measurements.

   Environment:

   • Codex App: 26.715.7063.0 (Microsoft Store)
   • Codex CLI: 0.144.6
   • Windows 11 x64 running in a VM
   • ChatGPT Pro
   • Native Windows sandbox: workspace-write + [windows] sandbox = "elevated"

   Observed with one active local task:

   • Task Manager showed 6 concurrent codex-windows-sandbox-setup.exe processes.
   • Aggregate Codex disk write rate was about 24.2 MB/s; individual setup helpers showed roughly 3.5–4.6 MB/s.
   • The sandbox log showed three setup helpers spawned within milliseconds when the task issued three tool calls in parallel.
   • Each helper independently granted the same write ACEs to the same roots (visualization output, %TEMP%, workspace parent, and current workspace), then ran read-acl-only mode: applying read ACLs.
   • All completed with errors=[]; this was not an error/retry loop.
   • The three identical scans each took about 17 seconds.

   The dominant root was %TEMP%, which contained:

   • 36,686 files
   • 25,525 directories
   • 1.94 GiB
   • One stale node-compile-cache alone contained 29,896 files.

   After deleting verified stale Temp caches/test profiles:

   • Temp fell to 4,968 files, 21,172 directories, 0.95 GiB.
   • The same sandbox setup pass fell from about 17 seconds to 3.3 seconds.
   • A subsequent 10-second idle sample showed 0 KB/s writes from the Codex process group, with zero setup helpers remaining.

   Additional findings:

   • Five stale node_repl.exe browser-helper children had accumulated under the active codex.exe across several hours. Disabling Browser/Chrome/Computer Use and the Node REPL MCP, then stopping those stale helpers, left zero.
   • Local Codex diagnostic/session storage was also large: logs_2.sqlite about 1.36 GiB and rollouts about 5.22 GiB.
   • The VM's 250 GiB system disk had only about 25 GiB free, and the machine had previously become unstable/crashed during these bursts.

   Current reversible mitigation:

   [features]
   multi_agent = false
   browser_use = false
   browser_use_external = false
   browser_use_full_cdp_access = false
   in_app_browser = false
   computer_use = false
   
   [agents]
   max_threads = 1
   
   [sandbox_workspace_write]
   exclude_tmpdir_env_var = true
   exclude_slash_tmp = true
   
   [mcp_servers.node_repl]
   enabled = false

   Requested fixes:

   1. Serialize/debounce identical Windows sandbox setup refreshes within a Codex process.
   2. Cache ACL state and avoid recursively reprocessing unchanged roots for every tool call.
   3. Coalesce parallel tool launches so they share one completed setup refresh.
   4. Avoid recursively scanning %TEMP% unless it is actually required as a writable root, and ensure the Temp exclusion settings are honored by Desktop sessions.
   5. Terminate Browser/Node helper processes when the owning task/tool session ends.
   6. Add rotation/size limits for diagnostic databases and rollout retention.

   No private project names, account identifiers, or credentials are included here.

   👍React with 👍1Reacted by wrighp
4. lvchongjun123-bot commented on Sep 6, 2026

   

   lvchongjun123-bot

   on Sep 6, 2026

   More actions

   Local reproduction: repeat setup refreshes and large temp/workspace scan

   Windows desktop 0.150.0-alpha.12.2:

   • Workspace E:\My-codex: about 85,486 files / 4.9 GB
   • %TEMP% before: about 12,709 files / 2.25 GB
   • %TEMP% after moving stale browser/automation caches: about 1,114 files /
     899 MB (11,596 files / 1.35 GB moved to recoverable backup)
   • Sandbox log contains repeated setup refresh: spawning codex-windows-sandbox-setup.exe with 2–5 launches in the same second
   • Disabling 8 optional MCP servers/plugins and enforcing
     agents.max_concurrent_threads_per_session = 1 made codex doctor report
     sandbox provisioning: complete

   This matches the earlier measurement in this issue: the same setup refresh is
   expensive when %TEMP% or a large workspace contains many small files, and
   parallel calls each launch their own helper.

   Suggested upstream improvements remain:

   1. Cache/serialize identical sandbox setup refreshes per Codex process.
   2. Avoid recursively re-processing unchanged temp/workspace roots.
   3. Coalesce parallel tool launches into one completed setup refresh.
   4. Provide a documented way to opt out of %TEMP%/large-tree read-ACL scans.