Sandbox causes significant managed `apply_patch` latency under `workspace-write` on Linux/WSL2

What version of Codex CLI is running?

0.147.0

What subscription do you have?

codex

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

WezTerm

Codex doctor report

What issue are you seeing?

Managed direct apply_patch operations incur several seconds of latency per filesystem mutation under workspace-write.

Representative timings:

Operation	workspace-write	danger-full-access
Create	3.6–5.3s	8ms
Update	6.0s	10ms
Delete	5.5–7.2s	9ms

The bundled local apply_patch executable remains effectively instantaneous when invoked through sandboxed exec_command. Git and ordinary filesystem operations are also fast.

There are no error messages—the issue is deterministic pre/post-mutation latency in the managed direct-tool/sandbox path. This appears related to #35376

What steps can reproduce the bug?

Environment:

• Codex CLI 0.147.0
• WSL2/Linux x86_64
• Native ext4 filesystem
• approval_policy = "on-request"

1. Configure and restart Codex:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

2. Give Codex this prompt:

Using the managed direct apply_patch tool, measure each operation separately:

1. Create /tmp/codex-managed-patch-probe.txt containing "created".
2. Read and verify it.
3. Update "created" to "updated" using apply_patch.
4. Read and verify it.
5. Delete it using apply_patch.
6. Verify it no longer exists.

Report wall-clock milliseconds for every operation.
Do not substitute shell redirection or another file-writing mechanism.

3. Managed create/update/delete operations take approximately 3–7 seconds each.

4. As a control, invoke the bundled patch executable through exec_command:

/usr/bin/time apply_patch <<'PATCH'
*** Begin Patch
*** Add File: /tmp/codex-local-patch-probe.txt
+probe
*** End Patch
PATCH

The actual local patch operation completes in effectively 0.00 seconds.

5. Change only the sandbox mode and restart Codex:

sandbox_mode = "danger-full-access"

6. Repeat the managed direct-tool prompt. Create/update/delete complete in approximately 8–10ms each.

7. Restore workspace-write and repeat. The multi-second latency returns.

Removing /tmp from explicit writable_roots does not resolve the issue because it remains writable through the default workspace policy.

This isolates the slowdown to the interaction between workspace-write and the managed direct apply_patch filesystem bridge, rather than patch parsing, WSL, ext4, or ordinary sandboxed command execution.

What is the expected behavior?

No response

Additional information

No response

Start by reproducing the managed direct apply_patch create, update, and delete timings under workspace-write, then compare them with danger-full-access and the bundled executable through exec_command. No source files or tests are named, so trace the managed direct-tool and sandbox filesystem bridge from those reproductions. Done means the workspace-write operations remain correct without the reported multi-second per-mutation latency.