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 82 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. 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.

If you want the unfiltered view of what is listening, that is exactly what the Network tool is for. Servers is the short list; Network is the whole truth.

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.

Open the Network tool first — if the port is there but the server is not, it is a filtering question rather than a detection one. Work through the missing-server checklist for the rest.