Next Is Not Recognized As An Internal Or External Command

The Next.js next command fails when your shell can’t find the runner your project needs to start.

You run a dev script, the screen flashes, and the terminal throws the error. It feels like the project is broken, yet the real issue is usually simple: Windows can’t locate the next executable that should be created when you install your project’s packages.

This guide walks through the fixes that solve it in real projects: Next.js apps, monorepos, fresh installs, and machines that recently updated Node or moved folders. You’ll start with quick checks, then move to deeper repairs that stop the error from returning.

Once it’s fixed, your dev server starts with one command right away.

Why This Error Happens In Plain Terms

When you type a command, Windows searches a short list of folders for an executable with that name. In a Next.js project, next is not a built-in Windows command. It’s a file installed by your package manager, usually under your project’s node_modules folder.

If the next executable isn’t installed, or your script isn’t calling it the way Node expects, Windows can’t find it and prints the message. The same line can also appear if you are running the command in the wrong folder, using the wrong shell, or pointing at a Node install that’s missing basic paths.

Fast Clue From One Command

Run this in the same terminal where you saw the error:

Check Your Working Folder — Run cd (or pwd in some shells) and confirm you’re inside the Next.js project folder.
Check If Next Exists Locally — Run dir node_modules\.bin\next* and see whether a file shows up.
Check Your Package Scripts — Open package.json and confirm your dev script calls next dev.

If node_modules\.bin has no next file, the fix is installation-related. If it exists, the fix is usually about the shell, the script, or where you’re running it from.

Quick Fixes That Solve Most Cases

Start here. These steps cover the most common reasons a machine throws next is not recognized as an internal or external command during a normal npm run dev or yarn dev.

Run The Script, Not The Raw Command — Use npm run dev, pnpm dev, or yarn dev so the tool can wire up local binaries for you.
Reinstall Packages Cleanly — Delete node_modules and your lockfile, then reinstall so next gets rebuilt in .bin.
Confirm Next Is A Dependency — In package.json, ensure next appears under dependencies (or devDependencies for certain setups).
Use The Right Node Version — Check node -v and match it to the Next.js version you’re using. A mismatched Node can break installs.
Restart The Terminal — Close the shell, reopen it, and run the script again so refreshed paths apply.

Most of the time, the clean reinstall fixes it. If you want the cleanest reset, remove node_modules, remove the lockfile, then run one install command and stick with it.

Taking “Next Is Not Recognized As An Internal Or External Command” From Symptom To Fix

This section maps common situations to direct repairs. Read the row that matches what you’re seeing, then apply the fix right away.

What You See	Most Likely Cause	What To Do Next
Error after cloning a repo	Packages not installed yet	Run `npm install` (or your repo’s package tool), then rerun `npm run dev`
`node_modules\.bin\next` missing	`next` not listed as dependency	Add `next`, reinstall, then run the dev script
Error only in one terminal app	Shell session using stale paths	Close that terminal, reopen, then run the same script again
Error when typing `next dev` directly	Local binary not on command search path	Run `npm run dev` so the local binary is found
Error after switching Node versions	Native modules and bins out of sync	Remove `node_modules`, reinstall, rerun the script

If your case isn’t in the table, don’t sweat it. The deeper steps below cover the rarer causes that show up in older machines, strict corp laptops, and multi-package setups.

Step-By-Step Repairs For Windows Shell Issues

Sometimes the packages are fine, yet Windows still can’t run the command from where you’re calling it. This often happens when Node itself is not reachable from the terminal you’re using, or when a script is being executed under a different user context than your interactive window.

Confirm Node And Npm Are Reachable

Check Node Availability — Run node -v. If the command fails, install Node again or fix the Node path.
Check Npm Availability — Run npm -v. If this fails, Node is not installed cleanly on that machine.
Check Where Node Comes From — Run where node and confirm it points to the expected install folder.

If where node returns nothing, your shell cannot see the Node install. On Windows 10 and 11 you can fix that through the system variable editor: open Start, search “Edit the system variables”, open it, go to the Advanced tab, open the variables button, and add the folder that contains node.exe to the Path list. A terminal restart is required after the change. The UI flow is outlined in common Windows guides.

Run The Correct Command From The Correct Place

Start In The Project Folder — Use cd into the folder that contains package.json.
Run The Script — Use npm run dev instead of typing next dev from a random folder.
Use A Clean Shell — Try a fresh Command Prompt or PowerShell window to rule out terminal plug-ins.

On some setups, typing next directly works only when the global install exists. That global install is not needed for most projects, and it can even mask broken local installs. Stick to project scripts so your repo stays portable across machines.

Handle Script Execution In PowerShell

If you see a message like “The term ‘next’ is not recognized…” in PowerShell, the root cause is still path lookup. One more PowerShell-specific gotcha is local script execution: running a file in the current folder needs a .\ prefix in many cases.

Next.js-Specific Fixes That Stop The Error From Coming Back

If you’re building with Next.js, the cleanest long-term fix is to ensure the project installs and runs the same way on every machine. Small inconsistencies can keep sneaking the error back in after updates.

Keep One Package Manager Per Repo

Mixing npm, Yarn, and pnpm in the same project can create a weird mix of lockfiles and bin folders. Pick one and stick with it. If your repo already has a lockfile, treat that as the source of truth and remove the others.

Pick One Tool — Use npm, Yarn, or pnpm, not a rotation of all three.
Use The Existing Lockfile — If the repo has package-lock.json, run npm. If it has yarn.lock, run Yarn.
Reset Conflicting Files — Remove extra lockfiles, reinstall once, then commit the correct lockfile.

Install Next In The Project, Not Globally

A global install of Next.js can make a quick demo work, yet it creates drift between machines. A teammate without the global install hits the same error. A local dependency keeps the behavior stable.

Add Next As A Dependency — Run npm i next (or the equivalent for your tool) in the project root.
Run Scripts From package.json — Keep dev, build, and start scripts using next.
Avoid Global Next Installs — Uninstall global Next if it’s hiding a broken local setup.

Fix A Broken Node Install Without Guesswork

If Node is installed, yet the terminal can’t run it, reinstalling Node from the official installer is often faster than chasing one-off path entries. After reinstall, open a fresh terminal and confirm node -v and npm -v work before touching your project.

Edge Cases: Batch Files, Monorepos, And CI

Most readers won’t need this section, yet if you keep getting the error after the usual fixes, you’re often in one of these situations. These cases can be sneaky because everything looks installed, yet the command is still unreachable in the context where it runs.

Running Next From A Batch File

If you’re wrapping your dev server in a .bat or .cmd file, keep two rules in mind. First, call scripts with call so control returns to your file. Second, if you use labels, jump with goto and confirm the label exists. Microsoft documents goto label handling for batch files.

Call Npm Scripts — Use call npm run dev inside batch files so the file doesn’t exit early.
Keep Labels Clean — Use :start, :end, then jump with goto start.
Use Windows Line Endings — If a batch label can’t be found, check the file’s line endings and save as CRLF.

Monorepos And Workspace Tools

In a monorepo, the app you’re running might not be the folder you’re standing in. The next binary may live in a workspace root, while your app script runs in a subfolder. A script that assumes a local node_modules will fail.

Run From The Workspace Root — Use the repo’s root command that targets the app package.
Check The Package’s Scripts — Ensure the app package has next available from its dependency graph.
Use Workspace-Aware Commands — Use your tool’s workspace run syntax so the right package context is used.

CI And Remote Build Agents

If the error happens in CI, the fix is rarely “add a global install.” It’s almost always a missing install step or a cache that kept stale bins around.

Install Before Running — Ensure the pipeline runs npm ci or the repo’s install command before npm run build.
Clear Cache When Node Changes — If your pipeline changed Node versions, clear package caches tied to the old version.
Print The Bin Folder — Add a debug step that lists node_modules/.bin so you can see whether next exists.

A Clean Checklist For Next Time

When next is not recognized as an internal or external command shows up again, run this checklist in order. It’s designed to keep you from bouncing between random fixes.

Start In The Right Folder — Confirm the folder contains package.json, then rerun the dev script.
Verify Next Is Installed — Check node_modules\.bin for a next file.
Reinstall Once — Remove node_modules and reinstall with the repo’s chosen package tool.
Confirm Node Works — Run node -v and npm -v in the same terminal window.
Restart Your Shell — Close the terminal, reopen, and rerun the script.
Remove Global Drift — Uninstall any global Next.js package that masks a local issue.

If you follow the checklist top to bottom, you’ll fix the cause and get back to coding.