[BUG] preview_start forces a bundled pnpm 11.17 and ignores the project's pinned packageManager, cannot start dev server

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?

preview_start (the in-app Browser-pane dev-server launcher) runs a pnpm preflight using a bundled pnpm 11.17.0 invoked under corepack. In a repo that pins an older pnpm via packageManager (mine pins pnpm@10.33.0), pnpm 11's self-guard aborts and the preview server never starts:

[ERROR] This project is configured to use 10.33.0 of pnpm. Your current pnpm is v11.17.0
Corepack invoked pnpm with this version, and pnpm does not switch versions when running under corepack.

This happens even when the launch.json command contains no pnpm at all, which isolates it to the harness's own preflight rather than the configured command.

Steps to Reproduce

1. Node project whose root package.json pins an older pnpm, e.g. "packageManager": "pnpm@10.33.0".
2. On the machine, corepack's global default resolves to a newer pnpm (here 11.17.0).
3. Add .claude/launch.json that starts a dev server (Next.js next dev), via corepack pnpm … dev or directly.
4. Call preview_start for that config.

Expected

preview_start respects the repo's packageManager pin (as plain corepack pnpm does when run in the repo) and starts with pnpm 10.33.0 — or, if runtimeExecutable isn't pnpm, skips the pnpm preflight entirely.

Actual

Fails with the pnpm 11.17.0 version-mismatch error above; the server never launches, regardless of the launch.json command.

Key finding (isolates it to the harness, not the machine or config)

1. Repo pin is honored outside the harness. In a clean non-interactive shell in the repo, corepack pnpm --version → 10.33.0. The normal Bash tool and a real terminal both resolve node v22.23.1 + corepack pnpm 10.33.0.
2. Removed the machine's global pnpm pin (~/.cache/node/corepack/lastKnownGood.json, which pinned pnpm@11.17.0) → corepack derives from packageManager everywhere else, but preview_start still reported 11.17.0.
3. Aligned default Node (fnm default → v22.23.1) and added ~/.zshenv so non-interactive shells get the toolchain → every other context works; preview_start still reported 11.17.0.
4. Removed pnpm from the launch command entirely — runtimeExecutable = absolute path to Node v22, runtimeArgs = ["apps/web/node_modules/next/dist/bin/next","dev","apps/web","-p","3030","--turbopack"] (zero pnpm/corepack) → still fails with the identical pnpm 11.17.0 error.

Since a pure Node+Next command still triggers a pnpm version error, preview_start runs its own pnpm preflight with a pnpm it carries/selects itself, ignoring the repo's packageManager pin, the user's shell env / ~/.zshenv, the fnm-active Node, and the corepack cache. Running the exact same next dev via the Bash tool works perfectly (Turbopack ready ~350–420ms, all routes HTTP 200).

Impact

Any team pinning packageManager to a pnpm older than the harness's bundled pnpm cannot use the in-app preview pane. Pinning packageManager is the recommended reproducibility practice, so this penalizes correctly-configured repos. Workaround: start the dev server via the Bash tool and open the localhost URL in an external browser (loses the preview pane's auto-start).

Suggested fixes (any one)

1. Before the pnpm preflight, resolve the project's packageManager pin (run corepack pnpm in the project dir, or a project-local pnpm) instead of a bundled pnpm.
2. When launch.json provides a runtimeExecutable that isn't pnpm, skip the pnpm preflight and run the configured command.
3. Spawn the preview process through a login/interactive shell (or otherwise source the user's env) so ~/.zshenv / fnm / corepack resolution matches the terminal and Bash tool.
4. Honor pnpm's --pm-on-fail/pmOnFail escape, or let the config opt out of the preflight.

Related

• #54135 (Claude Desktop NodeJS Env + NVM Path Sorting) — different mechanism (NVM glob ordering picks the wrong Node), same root family: the preview/desktop harness doesn't resolve the user's Node / package-manager environment the way the terminal does. Fixing env resolution in the harness would likely address both.

Environment

• Claude Code: 1.24012.9 (03c61d) 2026-07-24T04:59:17.000Z
• Surface: in-app Browser pane (preview_start with .claude/launch.json)
• OS: macOS 26.5.2 (arm64)
• Node (project-pinned, on PATH): v22.23.1
• corepack: 0.34.6
• Project pin: packageManager: "pnpm@10.33.0" (every workspace)
• Machine pnpm (corepack-cached): 10.33.0, 11.17.0, 9.15.4