Sandbox mode blocks named pipe creation on native Windows (EACCES), contradicting docs that say sandboxing is WSL2-only

Environment

• OS: Windows 11 Home, build 10.0.26200
• Execution mode: native Windows (not WSL2)
• Claude Code versions affected:
• v2.1.201 (installed via npm)
• v2.1.202 (bundled with Claude Desktop)
• Shell used by the Bash tool: Git Bash (MINGW64)

Summary

When a child process spawned through the Bash tool (in sandbox mode) attempts to create a Windows named pipe (\\.\pipe\cxc-<id>-codex-app-server, used by the OpenAI Codex plugin's shared runtime), the operation fails with:

EACCES: permission denied

The same operation succeeds when run through the PowerShell tool (outside the sandbox) and also succeeds when dangerouslyDisableSandbox: true is set on the Bash tool call — confirming the failure is caused by sandbox enforcement.

Expected vs. actual behavior

According to the official documentation, sandbox isolation is only supported under WSL2, and native Windows (including Git Bash) is explicitly not supported/sandboxed. In practice, however, native Windows sessions are still subject to sandbox-like restrictions — specifically, named pipe creation is being denied — which contradicts the documented behavior. Either the documentation is out of date, or sandbox enforcement is unintentionally being applied on native Windows.

Timeline

• Through 2026-07-05: named pipe creation succeeded normally.
• 2026-07-06 11:16: npm package auto-updated to v2.1.201.
• From 2026-07-07 onward: named pipe creation began failing with EACCES: permission denied.

This timing suggests the version update introduced sandbox-style restrictions that now also apply to native Windows sessions, where previously they did not.

Steps to reproduce

1. On native Windows 11 (not WSL2), install/update Claude Code to v2.1.201 (npm) or use Claude Desktop v2.1.202.
2. Use a plugin/tool whose shared runtime creates a Windows named pipe (e.g., the OpenAI Codex plugin's codex-app-server, pipe name pattern \\.\pipe\cxc-<id>-codex-app-server).
3. Trigger the pipe-creating operation via the Bash tool (Git Bash / MINGW64) with sandbox mode active.
4. Observe EACCES: permission denied.
5. Trigger the same operation via the PowerShell tool (outside the sandbox), or via the Bash tool with dangerouslyDisableSandbox: true — both succeed, isolating sandbox enforcement as the cause.

Questions

1. Is the current sandbox behavior on native Windows intentional (i.e., is the documentation simply out of date), or is this a bug where sandbox restrictions are being applied where they shouldn't be?
2. Is there a configuration option to permit named pipe creation from within the sandbox on native Windows?
3. What is the recommended workaround for native Windows users — is migrating to WSL2 the recommended path, or is there a supported way to keep using native Windows/Git Bash with this plugin runtime?