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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

```shell
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. (.../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.

Start with the Browser pane's server-launch tool and its named launch.json configuration, then reproduce with a fresh port using npm run dev in a Vite 8+ project. Inspect the macOS system log for Sandbox file-read-data denials involving node_modules/@rolldown/binding-darwin-arm64/rolldown-binding.darwin-arm64.node and compare the Browser-pane spawn with a direct Bash launch. Done means the configured dev server starts normally.

Scritto dal modello di indicizzazione a partire dal testo della issue.