All published 8.0.0-rc CLIs crash at startup: @prisma/cli-engine@0.1.1 lacks the readActiveAccessToken export

[ankur-arch]

Summary

Every published 8.0.0-rc build of the unified CLI (prisma@next = 8.0.0-rc.3/rc.4, @prisma/cli@next = 8.0.0-rc.3/rc.4) crashes at import time, before any command runs:

file:///.../node_modules/@prisma/cli/dist/cli.js:4
import { ..., readActiveAccessToken, ... } from "@prisma/cli-engine";
SyntaxError: The requested module '@prisma/cli-engine' does not provide an export named 'readActiveAccessToken'

Cause

• @prisma/cli@8.0.0-rc.3 and rc.4 both pin @prisma/cli-engine to exactly 0.1.1.
• Published @prisma/cli-engine@0.1.1 (2026-08-17) does not export readActiveAccessToken (grep -c readActiveAccessToken node_modules/@prisma/cli-engine/dist/index.js → 0).
• Repo HEAD's packages/cli-engine (also versioned 0.1.1) does export it (src/exports/index.ts, src/active-access-token.ts), so the CLI was published against an engine state that was never published. dist-tags now show dev: 0.2.0, but the rc CLIs' exact pin keeps resolving the broken 0.1.1.

Repro

npx -y @prisma/cli@next --version   # SyntaxError above (Node 24.11.1, macOS)
npx -y prisma@next --version        # same
npx -y @prisma/cli@8.0.0-rc.3 --version  # same

Impact

• Every npx @prisma/cli@next … / npx prisma@next … command in the docs fails today.
• It cascades: orm init scaffolds a project, installs @prisma/cli@next as a devDependency, then shells out to it for the initial contract emit — so orm init ends with CLI.INIT_EMIT_FAILED for every new user (exit code 5).

Suggested fix

Publish a cli-engine version containing the new exports and republish the rc CLIs pinned to it (or add a publish-pipeline check that installs the packed CLI tarball and runs --version before tagging next — docs/oss/release-automation.md already records a similar miss for @prisma/composer-cli@0.6.0).

Found while validating the docs against 8.0.0-rc.4 (prisma/web#8151); the repo-built CLI works fine, published artifacts do not.

🤖 Filed with Claude Code on behalf of datta@prisma.io

[ankur-arch]

Status as of today (2026-08-18):

• Reconfirmed the crash on the published artifacts: npx -y prisma@next --version (resolves 8.0.0-rc.4) still fails with SyntaxError: The requested module '@prisma/cli-engine' does not provide an export named 'readActiveAccessToken' on Node 24.11.1/macOS. Both prisma@8.0.0-rc.4 and @prisma/cli@8.0.0-rc.4 pin @prisma/cli-engine@0.1.1 exactly.
• @prisma/cli-engine@0.2.0 (with the missing exports) published today at 08:21 UTC, and chore(release): bump to 8.0.0-rc.5 #207 is the rc.5 release PR — but chore(release): bump to 8.0.0-rc.5 #207 as written would have re-shipped the crash: packages/prisma still pinned workspace:0.1.1, which pnpm publish publishes verbatim as 0.1.1. The engine bump tooling only rewrote packages/cli's pin, and no check compared a sibling's pin to the engine version actually shipping.
• The engine pin lives in two manifests, and only one ever moved #210 fixes the stale pin, makes bump-cli-engine-version rewrite every consumer manifest, and adds the publish-pipeline guard this issue suggested: release-channel conformance now fails with engine-pin-mismatch when any packed sibling pins an engine version other than the one packed beside it.

This issue closes when rc.5 (rebased on #210) is on next and npx -y prisma@next --version succeeds.

[ankur-arch]

Independent verification of the fix on the published stack (fresh npx cache, macOS, Node 24.11.1): npx -y prisma@next --version → {"ok":true,"result":{"version":"8.0.0-rc.5"},"exitCode":0}, with @prisma/cli-engine@0.2.0 resolved — where rc.4 crashed at import. The pipeline guard side landed in #210: the engine bump now rewrites every consumer manifest, and release-channel conformance fails when any packed sibling pins an engine version other than the one packed beside it (that check caught the stale packages/prisma pin that would have re-shipped this crash in rc.5).