prisma generate not working: "No command registered" (Prisma 8)

The error:

{"kind":"result","envelope":{"ok":false,"commandId":"","error":{"code":"CLI.UNKNOWN_COMMAND","severity":"error","summary":"No command registered for `generate`","nextActions":[{"kind":"run-command","label":"List every command","command":"prisma --help"}]}}}

Tested on: prisma (latest tag): 8.0.0-rc.20 · prisma / @prisma/client: 7.10.0 · Postgres: 17 (Docker) · Node / OS: 24.14.0 / Windows 11 Pro

Nothing is wrong with your schema. On npm, prisma@latest now points to 8.0.0-rc.20, a release candidate of Prisma ORM 8. It's a new command-line tool that doesn't read schema.prisma and has no generate, migrate dev or db push. Meanwhile @prisma/client@latest is still 7.10.0. So a fresh npm i prisma @prisma/client today gives you two different major versions, and every Prisma 7 tutorial breaks at the first command.

I checked it on October 7, 2026 with a fresh install:

$ npm view prisma dist-tags.latest
8.0.0-rc.20
$ npm view @prisma/client dist-tags.latest
7.10.0

These are the Prisma 7 commands I ran against it, each in the CLI's new JSON output:

You ran	Prisma 8 RC answered
npx prisma generate	No command registered for `generate`
npx prisma migrate dev	No command registered for `migrate`, did you mean `migration`?
npx prisma db push	No command registered for `push`, did you mean `update`?
npx prisma validate	No command registered for `validate`

Check which CLI you have

npx prisma --version tells you straight away. Prisma 7 prints a table (prisma : 7.10.0, @prisma/client : 7.10.0 and so on). The 8 release candidate prints one line of JSON:

{"kind":"result","envelope":{"ok":true,"commandId":"version","result":{"version":"8.0.0-rc.20"},...}

If you see JSON, you're on Prisma 8.

The fix for an existing Prisma 7 app

Prisma 8 isn't final yet: Prisma's own release status page calls it a release candidate, with general availability expected in October 2026. The same page says Prisma 7 keeps getting bug fixes and security updates for 18 months after that. If you have a working Prisma 7 app, the move is a rewrite (no @prisma/client, a new schema format, new commands), not a version bump.

Pin the CLI to the same major version as your client:

npm i -D prisma@7

npm saves that as ^7.10.0, which stays on 7.x. Then the usual commands work again:

$ npx prisma generate
✔ Generated Prisma Client (7.10.0) to .\src\generated\prisma in 117ms
$ npx prisma migrate dev --name init
Datasource "db": PostgreSQL database "postgres", schema "public" at "localhost:55432"

✅ After the pin, generate, migrate dev and a real query (an upsert through @prisma/adapter-pg) all worked against Postgres 17.

Docker and CI: npx prisma without a version

This is where most of the breakage is. A Dockerfile or CI step that runs npx prisma generate in a place where Prisma isn't installed (a slim production image, a separate migration job) makes npx download whatever latest is. I ran it in an empty folder with only prisma/schema.prisma in it:

$ npx -y prisma generate
{"kind":"result","envelope":{"ok":false,...,"summary":"No command registered for `generate`",...}}

Public repos have been filing the same failure since early September: Docker images, Railway deploys, a self-hosted release script, and Prisma's own Claude Code plugin ("unpinned npx -y prisma mcp now resolves to 8.0.0").

Put the major version in the command itself:

npx -y prisma@7 generate

✅ In the same empty folder this printed ✔ Generated Prisma Client (7.10.0).

Better still, keep prisma in devDependencies with the ^7 range and install from your lockfile (npm ci) before running it. Then npx uses the local copy instead of downloading latest.

If you already ran prisma init on the new CLI

npx prisma init with 8.0.0-rc.20 doesn't create prisma/schema.prisma or .env. In my test it created:

• a prisma.config.ts that imports definePrismaConfig and only lists AI agents,
• .claude, .cursor, .agents and .devin folders with Prisma "skills" in them,
• a postinstall script in package.json: prisma skills sync || exit 0.

That config file breaks the old CLI even after the fix above. With it in place, Prisma 7.10.0 refused to start:

Failed to load config file "D:\nk-repro\prisma-init" as a TypeScript/JavaScript module.
Error: TypeError: (0 , _config.definePrismaConfig) is not a function

Replace prisma.config.ts with a Prisma 7 config (Prisma 7 reads the connection URL from here, not from the schema):

import 'dotenv/config';
import { defineConfig, env } from 'prisma/config';

export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { path: 'prisma/migrations' },
  datasource: { url: env('DATABASE_URL') },
});

Then delete the postinstall line, and the four agent folders if you don't want them.

✅ With this config, Prisma 7.10.0 printed Loaded Prisma config from prisma.config.ts and ran migrate dev normally.

Watch out for the update banner

Once the fix above is in, the Prisma 7 CLI shows an "update available" box at the end of some commands. Mine ended with:

│  Run the following to update                            │
│    npm i --save-dev prisma@latest                       │
│    npm i @prisma/client@latest                          │

Running that puts you straight back on the release candidate. Ignore it until you decide to move to Prisma 8 on purpose.

Moving to Prisma 8 instead

If you're starting a new project and want Prisma 8, these are the replacements from Prisma's migration page. I confirmed that the old names fail on 8.0.0-rc.20, but I haven't built a project on Prisma 8, so treat this as a map, not tested steps:

Prisma 7	Prisma 8 (per Prisma's docs)
prisma init	prisma orm init --write-env
prisma generate	prisma contract emit
prisma migrate dev	prisma db update, or prisma migration plan then prisma db migrate
prisma db push	prisma db init (empty database) or prisma db update
@prisma/client	one package per database, e.g. @prisma/orm-postgres

What didn't work

❌ Reinstalling @prisma/client. It was never the problem: it installs 7.10.0, the version that works. The CLI is the part that moved.

❌ Deleting node_modules and the lockfile. That makes it worse. A clean npm i prisma resolves latest again and brings the release candidate straight back, unless the version is pinned.

❌ Pinning the CLI but keeping the generated prisma.config.ts. Prisma 7 crashed on it with the definePrismaConfig is not a function error above.

How this was tested

A fresh npm project on Windows 11 with Node 24.14.0, created with npm i -D prisma and npm i @prisma/client on October 7, 2026, which installed prisma 8.0.0-rc.20 and @prisma/client 7.10.0. Every Prisma 7 command above was run against that CLI, then again after the fix, against Postgres 17 in Docker. The CI case was a folder containing only prisma/schema.prisma and .env, with nothing installed, running npx -y prisma generate and then the version-pinned command from the Docker section. npm dist-tags can change at any time: when Prisma 8 reaches its final release, latest will point to it for good, and the fix above stays the way to keep a Prisma 7 app running.

The code for every case above is public, so you can run it yourself: prisma-init and prisma-ci in nk-repro.

---

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.