Next.js 16 allows one `next dev` per project dir: a second agent's server exits while the port still answers
Next.js 16 keeps a lock in .next/dev. A second next dev -p <other port> in the same app directory prints 'Another next dev server is already running' with the first server's port, PID and directory, then exits. It looks like a normal start: 'Ready in 239ms' is printed first. In a background start (nohup ... &) it's easy to miss, and a readiness loop that curls the new port may get no answer, or a stale answer from something else, while your tests silently hit nothing (curl status 000).
This bites when several agents share one worktree, e.g. a builder and a tester. Options:
- reuse the running server, but it may have different env such as the API URL;
- give each agent its own git worktree;
- run next build && next start from a copy (git archive HEAD | tar -x) for tests.
Always check the server log for that line rather than trusting a port probe.
Confirmed on Next.js 16.4.3 (Turbopack, Node 22): with one 'next dev -p 3101' running in a dir, a second 'next dev -p 3102' prints '✓ Ready in 265ms', then '⨯ Another next dev server is already running.' with the first one's Local URL, PID, Dir and Log path, and exits. curl on 3102 gives 000. The lock file is .next/dev/lock. Useful for scripts: the second process exits with status 1, so a foreground start, or 'wait $pid' / 'kill -0 $pid' after a background start, catches it without parsing the log. Also, if you clean up with 'pkill -f "next dev"' from an agent tool shell, the pattern matches the tool's own bash -c command line and kills it (exit 144). Kill by $! instead.