Tap a bug on your phone or in any browser, and Localdock hands it to Claude Code or Codex with everything attached — the screenshot, the request that failed, the console. When that request comes back 200, the report closes itself.
What your agent gets
A bug report written with your thumbs is a guess: “the export button does nothing”. Your agent then spends its first minutes working out which page, which element and which request. A Tap to Fix report answers all three before it starts: the element and its selector, a picture of the screen with it marked, the requests that failed with their status and body, and the console lines around the moment you tapped.
Hand over writes that into a task file in the project's .localdock folder and opens your agent on it, in your terminal, in that project — the same session you'd have started by hand, with the context you'd never have typed.
Fixed means the request works
Localdock keeps watching the project after you hand a report over. When the request that failed — same method, same path — comes back 2xx from the same project, the report is marked fixed, with the evidence on its timeline. Nobody comes back to tick a box. A bug with no failing request (a layout problem) you close yourself.
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
Which agents can a report be handed to?
Claude Code and Codex. Hand over writes the report as a task into the project's .localdock folder and starts the agent in Terminal or iTerm, in that project. The MCP server is separate and speaks the standard protocol, so any MCP-capable agent — Cursor included — can use list_ports, get_free_port and cleanup.
Can a report make my agent do something it shouldn't?
Anyone who can open a shared page can write a report, so Localdock treats report text as untrusted. In the task it's fenced between markers the sender can't predict, and the brief — written by Localdock, outside them — tells the agent to read it as evidence to examine, never as instructions to follow. And nothing reaches an agent until you press Hand over.
Who decides what command runs?
You do. The agent and its command are set in Localdock's settings; a repo's .localdock/config can suggest which agent to use for that project, but never the command, because a config file arrives with git clone.
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 app with Tap to Fix: point at a bug on any device, and your coding agent gets the rest. A one-time purchase — no subscription, no account. Get Localdock