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

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