What this PR does

Switches dependency installation in CI and release to the pinned pnpm, so CI tests the same dependency graph that release ships. This completes Stages 2 and 3 of #10444, including retiring the root package-lock.json; npm publish and every npm run … script invocation are unchanged.

• CI and release install with corepack pnpm install --frozen-lockfile. That covers the seven install steps in the main CI workflow, the three in the release workflow (which keep --ignore-scripts and their explicit postinstall and generate steps), and the two in the VS Code companion release. The hoisted pnpm layout lets npm run keep working unchanged.

• setup-node no longer restores an npm cache. Nothing reads it any more. package-manager-cache: false is now explicit on every touched setup-node step. Without it, setup-node v5+ sees packageManager: pnpm@… in package.json and tries to cache pnpm before pnpm is on the PATH, which fails the step.

• A new composite action caches the pnpm store on hosted runners. It is keyed on pnpm-lock.yaml and used by the three jobs that always run on GitHub-hosted runners (web-shell E2E, macOS, Windows). The self-hosted ECS pool keeps its pnpm store on local disk between jobs, just as it does its npm cache today.

• Release versioning no longer lets npm rewrite the installed tree. npm version in workspaces reifies node_modules by default, and the old step 9 ran a full npm install. On a pnpm-installed tree that would not fail — it would silently turn the tree back into npm's layout, and the release would build against npm's graph after all. Both npm version calls now pass --no-workspaces-update, and step 9 refreshes package-lock.json only. pnpm-lock.yaml does not change on a version bump, because .pnpmfile.mjs rewrites every internal dependency to workspace:*.

• Scripts that located packages through package-lock.json keys now read what is installed.

  • The VS Code notices generator resolves each dependency with Node's own lookup over the installed tree, so the notices describe what the extension bundles, whichever package manager laid the tree out.
  • The sharp version pinned into the published CLI manifest is read the same way.
  • The standalone release reads every target's clipboard and OpenTUI native package version from pnpm-lock.yaml. Only the build host's own platform package is installed, so the installed tree cannot answer for the other targets; the lockfile the release installed from can.

• Undeclared zod peers resolve to the repo's zod, as they do under npm. The first CI run on this PR caught a real divergence. web-shell bundles @modelcontextprotocol/ext-apps, whose zod and MCP SDK are peers. web-shell declares no zod of its own, so pnpm filled that peer with the highest locked zod (4.4.3), while npm serves the hoisted 3.25.76.

  • The result: zod 4 landed in web-shell's transcript bundle (+100,903 bytes pre-minify), and the export renderer built from the same commit grew from 1,858,186 to 1,930,015 bytes, past its 1,930,000-byte budget.
  • This was confirmed by comparing both trees' esbuild metafiles and prebuilt bundles in CI. The whole difference is in transcript.js, and the added code is zod 4 plus the ext-apps schemas; the sdk daemon bundle is byte-identical.
  • The fix declares zod: 3.25.76 as a root devDependency. With resolve-peers-from-workspace-root (on by default in pnpm 11), every zod peer that a package does not declare itself now resolves to it, which is npm's hoisting behaviour. mobile-mcp keeps its own zod 4.4.3, as it does under npm. The npm tree does not change.

• Root-level typechecks see npm's root @types/node. The second CI run caught a second divergence of the same shape. The no-AK integration gate typechecks integration-tests/, which takes Node's types from the root node_modules.

  • npm hoists @types/node 20.19.1 there, because acp-bridge and core pin it.
  • pnpm, with no root declaration, hoisted 22.20.1. Its spawnSync overloads type process-registry.ts's stdout as string | NonSharedBuffer, which fails TS2322.
  • The same code passes on every npm-installed PR.
  • Declaring @types/node: 20.19.1 at the root puts npm's copy back where a root-level tsconfig looks. The npm tree does not change.

• Root-level code can import workspace packages, as it can under npm. The third CI run caught a third divergence. npm links every workspace package into the root node_modules, so integration-tests/ and scripts/ — which are not workspace packages themselves — import @qwen-code/* by name. pnpm links a workspace package only where it is a declared dependency, and the root declared none, so the no-AK integration gate could not find @qwen-code/qwen-code-core.

  • The root now declares, as file: devDependencies, the seven packages that root-level code imports at runtime: acp-bridge, channel-base, the CLI, core, sdk, web-shell and web-templates.
  • npm already links them, so its tree does not change; letting npm re-resolve the lock reproduces the same root entry.
  • .pnpmfile.mjs rewrites them to workspace:*, which pnpm links at the root.

• NOTICES.txt is regenerated from a pnpm-installed tree.

• Every other workflow that installs the root workspace switches too, so no job tests a graph that release does not ship. That covers:

  • e2e, tui-parity, repo-hygiene, web-shell-visuals, serve-ab, sdk-java, windows-runner-smoke and qwen-autofix;
  • the SDK releases, finalize-release and sync-release-to-oss;
  • the root installs in desktop-release and cd-cua-driver;
  • the sandbox Dockerfile.

  Hosted jobs restore the pnpm store through the same composite action, except in qwen-autofix. Its heavy jobs forbid local uses: './…' actions, so its hosted fallback installs cold, and the persistent pool still restores no remote cache (af-012). serve-ab and web-shell-visuals also install a separate base checkout, which can predate pnpm-lock.yaml, so those installs fall back to npm ci when the lockfile is absent.

• The qwen-triage verify and tmux-testing lanes install the PR with pnpm. They still restore a shared store read-only, now a pnpm store keyed on pnpm-lock.yaml, and run corepack pnpm install --frozen-lockfile --store-dir … as the unprivileged node user. The single install retry now clears node_modules first, because pnpm install, unlike npm ci, keeps it. npm-cache.yml becomes pnpm-store.yml, which fills and saves that store on the same runner and container image.

• The dependency CVE gate audits the root workspace with pnpm audit --prod --audit-level high. pnpm reads pnpm-lock.yaml directly, so the root install step goes. The two vendored lockfiles outside the pnpm workspace keep npm ci and npm audit. The retry also recognises pnpm's endpoint error, ERR_PNPM_AUDIT_BAD_RESPONSE. Run against this lockfile, pnpm audit reports 1 low and 4 moderate advisories, and no high.

• The root package-lock.json is retired; pnpm-lock.yaml is the only root lockfile.

  • npm run check:lockfile keeps the pnpm integrity check and the Playwright parity check, which now reads pnpm's importers and snapshots. The npm-vs-pnpm version agreement and the build-approval check go: pnpm 11's strictDepBuilds and every CI install's --frozen-lockfile already enforce what they covered.
  • pnpm-lock-freshness.yml goes, since it regenerated pnpm-lock.yaml from package-lock.json.
  • Release: version.js drops its package-lock refresh, the release commit stages pnpm-lock.yaml instead, and the SDK release stages no lockfile; both git adds would otherwise fail on the missing file. npm version in the SDK and mobile-mcp releases passes --no-workspaces-update, so it cannot reinstall the root with npm.
  • cd-mobile-mcp installs from the root pnpm lockfile, which is where its npm ci inside the workspace used to read the npm one. setup-node in cd-mobile-mcp, qwen-code-pr-review and desktop-release no longer keys an npm cache on the root lockfile, which would fail the step once the file is gone.
  • check:desktop-isolation reads pnpm importers; build.js, build_sandbox.js and preflight install with pnpm.
  • pnpm-lock.yaml, pnpm-workspace.yaml and .pnpmfile.mjs join the autofix supply-chain class and repo-hygiene's write deny list. pnpm-lock.yaml also joins autofix's generated-diff exclusions, sdk-java's path filter and the platform-sensitivity manifests.
  • .gitignore lists /package-lock.json, so an npm install cannot commit it back.

• qwen review installs pnpm repos. Its build/test step installed only a repo with package-lock.json and reported a pnpm repo as unsupported, so reviews of qwen-code would have lost their build and test. It now picks the installer from the committed lockfile (with both, packageManager: pnpm@… chooses pnpm), runs corepack pnpm install --frozen-lockfile through the same disk, budget and sandbox path as npm ci, and counts the tree as installed once node_modules/.modules.yaml exists. Scripts still run through npm run, and npm repos are unaffected.

• Deliberately unchanged: packages with their own lockfile keep npm ci — cua-driver's TypeScript SDK, desktop-shell and live-host.

• Touched workflows get new size baselines. Most were already over their recorded baselines on main, so any edit engages the ratchet; the new numbers are their sizes after this change. qwen-autofix.yml stays under the 470,000-byte absolute gate, with 3,261 bytes of headroom.

• AGENTS.md, CONTRIBUTING.md and the npm workspace guide install with pnpm. Dependency changes now go through corepack pnpm install or corepack pnpm add, committing pnpm-lock.yaml.

Why it's needed

Switching only CI would leave CI testing a different graph from the one release ships. Measured against the committed lockfiles, 13 direct dependencies still resolve to different versions under npm and pnpm. Among them are fdir and picomatch, which core bundles into the CLI, and esbuild, which produces the bundle. Moving release installs in the same change keeps a single graph. The version-bump fix is what makes that true in practice rather than on paper.

Reviewer Test Plan

How to verify

• This PR's own CI is the parity run. The enabled Linux test, lint/static and integration lanes run on the ECS pool; hosted runners cover web-shell E2E, the macOS and Windows install jobs, and Windows Desktop Shell. The full macOS and Windows Test lanes are skipped by PR classification. Every executed lane installs with pnpm and runs the existing npm run scripts unchanged. Green here is the evidence the switch needs.
• The NOTICES check in Lint & Static passes against the regenerated file, which proves the generator produces the same output on CI's tree.
• The standalone release still stages the right native packages: the clipboard spec list read from pnpm-lock.yaml is unchanged (@teddyzhu/clipboard*@0.0.5 for every target), and the existing install-script test pins it.
• Before merging, run a release dry-run from this branch — the release workflow's dry_run input. It is the only thing that exercises release installation, the version bump and the standalone archives end to end.

Evidence (Before & After)

N/A. Tooling only.

Tested on

Run locally: Prettier's experimental CLI and ESLint on every changed file, syntax and YAML parsing, and the clipboard spec reader against the committed pnpm-lock.yaml. Not run locally: any install, build, test suite, or workflow — the PR CI provides the full Linux test lane plus cross-platform installation coverage from the macOS and Windows install jobs and Windows Desktop Shell.

Environment (optional)

N/A

Risk & Scope

• First pnpm run on the ECS pool. These runners reuse their pre-installed Node, so this is the first time Corepack fetches pnpm through that egress path. The CI on this PR, which runs on the pool, is where that shows up first.
• pnpm 11's supply-chain policies now apply to every CI run, not only the opt-in smoke job. minimumReleaseAge defaults to one day, so a dependency bump to a version published less than 24 hours ago fails CI until it ages. strictDepBuilds fails an install script nobody approved. Both are the point of the migration, but they are new failure modes for dependency PRs.
• The pnpm store on ECS hosts grows without pruning. The same is true of the npm cache today. A prune schedule is a follow-up.
• The triage store starts cold. pnpm-store.yml runs on the merge push, because this PR changes pnpm-lock.yaml. Until it finishes, triage restores miss and download from the registry.
• Reviews run the published CLI. qwen-code-pr-review installs @qwen-code/qwen-code@latest, so reviews keep today's behaviour until a release ships this PR's qwen review change. That behaviour is not fatal: without package-lock.json it reports the repo as unsupported and tells the reviewer to install dependencies itself, so reviews are slower and less scoped until then.
• Breaking changes / migration notes: npm ci no longer works at the repository root, because package-lock.json is gone. Install with corepack pnpm install --frozen-lockfile, as CI does, and change dependencies with corepack pnpm add or corepack pnpm install so that pnpm-lock.yaml is updated. Open PRs that edit package-lock.json need to make that change in pnpm-lock.yaml instead.

Linked Issues

Part of #10444: completes Stage 2 and Stage 3.