Coding agents start dev servers on whatever port is free, so the URL in your browser goes stale several times a day. Localdock gives every project one stable address — dashboard.localhost — that follows the newest server automatically, whatever port it landed on.
The port lottery
Run two or three parallel sessions and the lottery starts: one agent takes 3000, the framework auto-increments the next run to 3001, then 3002, and the tab you have open is quietly pointing at an instance you stopped caring about an hour ago. You end up testing the server you forgot to kill, not the one doing the work.
The worst failure isn't RAM, it's “fixed” code
A busy port doesn't just waste memory. An agent that hits EADDRINUSE can decide the port error means the code is broken — and “fix” something that worked fine. The cost isn't the orphaned process; it's the working code that got mangled because a port was taken.
One name, whatever the port
Localdock's answer is to make the port irrelevant. dashboard.localhost resolves to whichever port the newest server in that project is on, so bookmarks, OAuth callbacks and README instructions stop breaking. No DNS, no hosts file, no admin password — here's how the name resolves — and the same name climbs to your phone and to a public link when a session's work needs to leave the machine (how that compares to a tunnel).
Three MCP tools, nothing else
The app ships an MCP server so agents can stay out of the mess in the first place. It exposes exactly three tools:
list_ports— every dev server on localhost with origin attribution (Claude Code / Cursor / terminal / IDE), its project, and its active, idle or orphaned state. The same list the Localdock UI shows.get_free_port— returns a free port and reserves it for 60 seconds, so parallel agent sessions can't be handed the same one and race.cleanup— frees localhost. With no arguments it terminates orphaned dev servers whose session is gone; given a port, it frees that exact port instead of letting an agent give up onEADDRINUSE. Always graceful — SIGTERM first, SIGKILL after three seconds — and it only ever touches processes visible inlist_ports.
When a server can't be traced to a session, Localdock says unknown origin — never a plausible guess, because a guess is exactly what you don't want feeding an autonomous cleanup.
The evidence
The vendors aren't cleaning this up — Anthropic closed the canonical orphaned-process issues as “not planned”. Real, citable reports:
A wrangler dev left running for 905+ hours after its session ended.
An orphaned next dev holding 8+ GB of RAM. Closed as “not planned”.
18 orphaned node processes, 51 GB of RAM, killed by a hand-rolled script.
Agents don't know a server is already running, so they start another one.
Questions
Does this work with Cursor, or only Claude Code?
Both, and anything else. The name-follows-the-server behaviour doesn't care what started the server, and the MCP server speaks the standard protocol, so any MCP-capable agent can use it. Attribution recognises Claude Code, Cursor, VS Code, iTerm and Terminal.app sessions — and anything it can't identify is labelled unknown origin rather than guessed.
Do I have to configure each project?
No. Names come from your project folders, so a server started in ~/code/dashboard is dashboard.localhost before you touch anything. Renaming is one click if the folder name isn't the name you think in.
What happens to servers an agent leaves behind?
Localdock notices when the session that started a server is gone, flags it as orphaned, and lets you (or an agent, via the cleanup tool) stop it gracefully — SIGTERM first, SIGKILL only after three seconds, and only ever for processes visible in the list.
Localdock is a macOS menubar app, a one-time purchase — no subscription, no account. Get Localdock