›_ Codex Issues
Codex Issues / #33737

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

Open 💬 3 comments Opened Jul 17, 2026 by dinjufen
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, local Codex tasks using the elevated sandbox repeatedly start
codex-windows-sandbox-setup.exe and recursively process a large pnpm workspace.

This saturates disk active time and causes apply_patch, rg searches, and
other tool calls to wait 30–130 seconds, even though the underlying command
usually completes in milliseconds or a few seconds.

Environment

  • Codex App version: 26.715.2305.0
  • OS: Windows
  • Shell: PowerShell
  • Sandbox: elevated / Ask for approval
  • Workspace: pnpm project with 1617 directories under node_modules/.pnpm
  • Git submodules: 3
  • Multiple local Codex tasks may access the same workspace concurrently

Symptoms

  • Disk active time reaches 100%
  • Approximately 4 MB/s reads and 70 MB/s writes
  • Multiple codex-windows-sandbox-setup.exe processes run concurrently
  • The processes have different codex.exe parent processes
  • Setup processes exit and are launched again shortly afterwards
  • Process Monitor shows many operations under node_modules/.pnpm and

submodules with results including:

  • INVALID PARAMETER
  • NO MORE FILES
  • apply_patch may already have written the file, but its completion response

does not return for 30–130 seconds

Measurements

With elevated sandbox/tool setup active:

  • Tool response latency: 30–130 seconds
  • Small file read inside the actual command: approximately 114 ms
  • rg operation inside the actual command: approximately 178 ms

Control test using danger-full-access:

  • Enumerating 1617 top-level .pnpm directories: 40 ms
  • git submodule status: approximately 2 seconds

This suggests the workspace filesystem itself is healthy and the delay is
caused by repeated Windows sandbox initialization/ACL processing.

Expected behavior

Sandbox initialization should be cached or avoid recursively reprocessing
large dependency trees for every task/tool invocation.

Concurrent tasks using the same workspace should not launch competing full
workspace scans.

Actual behavior

Each task appears to launch or relaunch
codex-windows-sandbox-setup.exe, causing metadata-heavy writes and disk
contention across all tasks.

Workarounds

  • Close other local Codex tasks
  • Use only one elevated-sandbox task at a time
  • Use danger-full-access for a trusted repository
  • Use Codex CLI instead of the Windows App

Attachments

  • /feedback session ID: 019f6a9d-2778-70c1-8557-99825e2554a8
  • Process Monitor filtered capture
  • Task Manager disk-performance screenshot

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33158
  • #33365
  • #33732

Powered by Codex Action

genusJoe · 1 month ago

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.

Showing cached comments. Read the full discussion on GitHub ↗