Give your agent a lane.

An agent that runs pnpm dev & loses the PID, the logs, and the port the moment a second agent does the same on the same machine. With devlanes it starts a lane, gets a URL to hand you, and the daemon takes care of the rest.

No lost PIDs, no port fights, no RAM eaten overnight.

Two agents on one machine both run the dev server in the background: the second one fails on port 3000 and never reads the log that says so. With devlanes each worktree is its own lane, the daemon owns the processes, and the agent's shell can end without anything dying. An hour later the lane is still there in your own status, with what it costs.

The daemon records what each agent session started, so the agent keeps track of nothing: devlanes stop --mine stops only its own units, across every lane, and leaves yours alone.

agent session · ~/dev/myapp-perf

you    start the stack and give me the URL

agent  devlanes start
       myapp@3 (agent/perf): 3/3 ready
       ready api    http://127.0.0.1:20030  https://api.myapp3.localhost
       ready web    http://127.0.0.1:20031  https://myapp3.localhost
       ready worker http://127.0.0.1:20032

agent  Your main branch was already running on lane 0, so this
       went up on lane 3: https://myapp3.localhost

you    done, shut it down

agent  devlanes stop --mine
       stopped myapp@3:api
       stopped myapp@3:web
       stopped myapp@3:worker

The plugin refuses a dev server started in the background.

The Claude Code and Codex plugin teaches the agent the CLI and runs a check before every shell call. A detached command that looks like a dev server, in a repository with a devlanes.yaml, is blocked, and the message says what to run instead and how to check on it afterwards.

agent session · ~/dev/myapp-perf

$ claude plugin marketplace add devlanes-run/devlanes
$ claude plugin install devlanes@devlanes

agent> pnpm dev &
Blocked by the devlanes plugin: this starts a long-running process in the background, where nothing supervises it and its logs are lost.
Use instead:
  devlanes start [UNIT...]               services defined in devlanes.yaml
  devlanes exec --name NAME -- COMMAND   any other long-running command
Then check it with `devlanes wait NAME --timeout 180s` and `devlanes logs NAME --tail 100`.

Tests run against the lane, then it is put back.

One command starts the lane, runs the tests with the lane's URLs in their environment, stops what it started and exits with the tests' code. The same line runs in CI.

agent session · ~/dev/myapp-perf

agent> devlanes with -- pnpm test:e2e
myapp@3 (agent/perf): 3/3 ready
  42 passed (38.2s)

An agent on a box. The URL it prints there opens here.

Lanes are not a sandbox: every process runs as you. For an agent you want contained, give it a VPS, a container or a codespace, run devlanes there, and connect to that box from your laptop. The hostname the agent prints is the one you open, with your own certificate.

on my-vps

$ devlanes url print web
https://myapp3.localhost
on laptop: https://myapp3.localhost

In the docs

Install devlanes

Homebrew

brew install devlanes-run/tap/devlanes

Shell script

curl -fsSL https://devlanes.run/install.sh | sh

PowerShell

irm https://devlanes.run/install.ps1 | iex

npm

npm install -g devlanes

uv

uv tool install devlanes

cargo binstall

cargo binstall --git https://github.com/devlanes-run/devlanes devlanes