Browser-pane dev-server launcher fails with EPERM (uv_cwd) -- sandboxed subprocess can't load an ad-hoc-signed native binary (Vite 8/Rolldown)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Starting a dev server via the Browser pane's server-launch tool (a named launch.json config running e.g. npm run dev) fails during startup with an EPERM: process.cwd failed with error operation not permitted, uv_cwd error, instead of starting normally.

Reproducible 100% of the time, across two unrelated projects in the same parent directory. A plain npm run dev run directly via the CLI's own Bash tool, in the identical directory, works with no issue -- so this is isolated to whatever process backs the Browser pane's own server-spawn mechanism, not the project or a general macOS permission problem with the directory itself.

What Should Happen?

The dev server starts normally, exactly as it does when the same command is run manually in Terminal.

Error Messages/Logs

Error: EPERM: process.cwd failed with error operation not permitted, uv_cwd
    at process.wrappedCwd (node:internal/bootstrap/switches/does_own_process_state:142:28)
    at process.cwd (.../npm/node_modules/graceful-fs/polyfills.js:10:19)
    at new Config (.../npm/node_modules/@npmcli/config/lib/index.js:80:19)
    at new Npm (.../npm/lib/npm.js:62:19)
    at module.exports (.../npm/lib/cli/entry.js:13:15)
    at module.exports (.../npm/lib/cli/validate-engines.js:33:10)
    at module.exports (.../npm/lib/cli.js:12:31)
    at Object.<anonymous> (.../npm/bin/npm-cli.js:2:25)
errno: -1, code: 'EPERM', syscall: 'uv_cwd'

Exit code 7.

Steps to Reproduce

1. Have a project using Vite 8+ (pulls in @rolldown/binding-darwin-arm64 as a native dependency).
2. Make sure nothing is already listening on the configured dev-server port, so the launcher actually attempts a fresh spawn rather than reusing an already-running server.
3. Start the dev server via the Browser pane's named launch.json config.

Expected: server starts normally.
Actual: immediate crash with the EPERM/uv_cwd error above (exit code 7).

Root cause investigation (best evidence available from outside the tool): the macOS system log (log show --predicate 'process == "kernel" and eventMessage contains "Sandbox"') shows real Sandbox: ... deny(1) file-read-data entries at the exact moments of the failures, for the project's node_modules/@rolldown/binding-darwin-arm64/rolldown-binding.darwin-arm64.node (Vite 8's native Rolldown bundler binary). That file is ad-hoc signed with no Team Identifier (codesign -dv output: flags=0x20002(adhoc,linker-signed), TeamIdentifier=not set) -- exactly the kind of artifact Hardened Runtime "library validation" refuses to load into a process descended from an app that enforces it. Whatever spawns the Browser pane's dev servers appears to run under that restriction; a Terminal/Bash-launched process doesn't.

This may be the first time this exact spawn path had ever actually run for either project -- every earlier session already had a dev server running (started manually, or left over from a prior session), so the launcher always found the port occupied and never needed to spawn a fresh process before this.

Workaround: start the server with a plain background shell command instead, then attach the Browser pane to the already-running server by URL rather than by name.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Unknown -- claude --version returns "command not found" in both the sandboxed session's own Bash tool and the user's own Terminal.app/zsh. See Additional Information.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This report was diagnosed and drafted by Claude Code during a live debugging session, then reviewed and submitted by the account owner.

One more relevant data point: claude --version returns "zsh: command not found: claude" in the user's own Terminal.app too, not just the sandboxed session -- so this may be running via a different integration (desktop app, IDE extension, etc.) than the npm-installed CLI binary the bug report template assumes. Happy to provide whatever other version-identifying info would help if this field's absence is a blocker.