go-live 2/9: v1 deprecation notice + publish 1.0.1 from v1/main (OIDC rehearsal)

[cliffhall]

Phase 2 of 9 in the v2 go-live runbook — see #1804 (§4). Depends on #1824.

⚠️ IRREVERSIBLE — this publishes to npm. A version number is consumed and cannot be unpublished in practice.

Ship the v1 deprecation notice as 1.0.1, published from v1/main. This doubles as the trusted-publishing rehearsal: it is the first evidence that OIDC publishing works from a non-default branch, which is what makes the whole "v1 keeps taking security fixes" story viable.

Two steps: a PR carrying the content change, then a release cut from the merged branch.

Step 1 — PR into v1/main

After #1824 the branch is ruleset-protected: 1 approving review, code-owner review, and a green build check. No direct pushes.

• Deprecation notice in all four published packages, not just the root.
  v1 publishes four names and each is separately installable, so each needs
  its own notice — a root-README-only change is invisible to anyone who
  installed a sub-package.

  | Package | Where the notice goes |
  | --- | --- |
  | `@modelcontextprotocol/inspector` (root) | `README.md` |
  | `@modelcontextprotocol/inspector-cli` | `cli/src/cli.ts` — stderr banner in `main()` (:376). Also covers the **root `mcp-inspector` bin**, which is `cli/build/cli.js`. Must be **stderr**, not stdout: `--cli` mode emits JSON on stdout and a banner there would corrupt piped output. |
  | `@modelcontextprotocol/inspector-server` | `server/src/index.ts` — alongside the existing `⚙️ Proxy server listening` log (:1091) |
  | `@modelcontextprotocol/inspector-client` | `client/bin/start.js` — next to the `🚀 MCP Inspector is up and running` log (:170); plus `client/README.md`, the only sub-package with one, and a dismissible banner in the web UI itself |
  
  Wording should match the `npm deprecate` text in #1816 so the npm warning
  and the runtime notice say the same thing: v1 is deprecated, use
  `@modelcontextprotocol/inspector@latest`, v1 gets security fixes only.
  
  Note `cli/` and `server/` have **no README**, so npm renders a blank page
  for those two — the runtime banner and the `npm deprecate` warning (#1816)
  are the only notice their users get.
  

• npm run update-version 1.0.1 — bumps all four (package.json + client/server/cli). The build job's check-version step fails if they drift, so this is enforced by the PR gate rather than trusted to memory.

• Do NOT add --tag v1 to publish-all in this PR. 1.0.1 must take latest — that is the entire point of shipping the notice to npx users. (--tag v1 is go-live 3/9: lock the v1 dist-tag and deprecate all four packages on npm #1816, immediately after.)

• Merge once build is green.

Step 2 — cut the release

gh release create 1.0.1 --target v1/main \
  --title "1.0.1 — v1 deprecated" \
  --notes "v1 is deprecated. Use @modelcontextprotocol/inspector@latest (v2). v1 receives security fixes only."

For a release event GitHub runs the workflow file from the commit the tag points at, so --target selects which main.yml executes. Tag has no v prefix, matching 1.0.0. The whole workflow runs — build (format, check-version, lint, tests) then publish, which is needs: build, so a failed check stops it before npm.

• gh run watch — approve the deployment if the release environment prompts.
• npm view @modelcontextprotocol/inspector dist-tags → latest: 1.0.1
• npm view @modelcontextprotocol/inspector-cli version → 1.0.1

Pre-flight (already checked)

• Settings → Environments → release → Deployment branches and tags = No restriction (verified 2026-07-27), so the tag reaches the publish job.
• If required reviewers are configured the run pauses for approval, it does not fail. We have someone with approval rights.
• v1's workflow already ensures npm ≥ 11.5.1 (Node 22 bundles 10.x).

Hazards

• Partial publish. publish-all is npm publish --workspaces && npm publish. Workspaces can land while the root fails, leaving the three sub-packages at 1.0.1 and the root at 1.0.0. Recoverable (bump to 1.0.2, go again), not clean — hence verifying both above.
• If the OIDC leg fails, nothing is burned but the tag. Fall back to the workflow_dispatch publish job on main described in plan: v2 go-live runbook — deprecate v1 (1.0.1), branch v1/main, swap main to v2, publish 2.0.0, close v1 backlog, restrict external PRs #1804 §4 — and keep that job inline in main.yml, since npm validates the calling workflow's filename and a reusable workflow_call breaks the match.

What this does not prove

The --tag v1 publish path, and a publish in the post-2.0.0 world where latest is genuinely at risk. The first real v1 security fix remains the first true exercise of that.

Blocks #1816.

[cliffhall]

Phase 2 complete. 1.0.1 published from v1/main — all four packages, latest: 1.0.1, no partial publish.

The OIDC rehearsal passed. Trusted publishing works from a non-default branch: npm matched on repo + workflow filename + release environment with no branch/ref pinning, exactly as #1804 §4 predicted from the docs. That is now evidence rather than a reading, and it is what makes the "v1 keeps taking security fixes from v1/main" story real. The release environment let it through with no approval pause, and --provenance was fine (workflow ref and published tree are the same commit here).

Verified against the published tarball, not just registry metadata — the deprecation banner is present in the shipped cli/build/cli.js.

⚠️ #1816 is now urgent. publish-all still has no --tag, so any future v1 publish takes latest. Once 2.0.0 ships, that gap is where a v1 security fix silently steals latest back.