How detection works

Pip enumerates the machine's listening sockets and the processes behind them, then decides which of those are development servers. A process qualifies if it matches any one of three signals:

• A known dev runtime. Pip recognises 80 of them — Node, Vite, Python, .NET, Rails, Go, and the rest of the usual suspects.
• A working directory inside a git repository. If the process was started from a repo, it is almost certainly yours.
• A conventional dev port. 28 of them — 3000, 5173, 8000 and their neighbours carry a strong enough hint on their own.

One signal is enough. That is why a server you started five seconds ago, in a brand-new project, on a port nobody has heard of, still turns up.

Everything else on the machine is listening to something too. Left alone, the list would be an unreadable inventory of Windows itself, so two categories are dropped before you ever see them:

• Privileged ports — anything below 1024, which on a developer machine is the operating system, not you.
• OS service processes — the background machinery Windows runs whether or not you are working.

The filter never hides anything about a server Pip does show: open its detail screen and the Ports tab lists every address it is bound to, exposed or not — more in the Servers guide.

The scanner runs every 5 seconds and the metrics sampler every 1.5 seconds. A server you start in your terminal appears within one scan; one you stop disappears just as quickly.

The engine reports deltas rather than snapshots, so on an idle machine it emits nothing at all. That is why a tool watching everything you run does not itself become something worth watching.

A server that never appears is usually one of three things: it is not actually listening yet, it is bound to a privileged port, or it was started by an elevated process.

Work through the missing-server checklist — and if it comes up empty, tell us the runtime and the port. Detection gaps are bugs, and they get fixed.