Skip to main content
Run is the project’s home surface and its execution dashboard in one. For a fresh install it’s the welcome screen that opens, creates, or clones a repository. Once a project is loaded it becomes the per-lane runtime dashboard: a grid of the dev processes and test commands your project defines, each startable per lane, with status, ports, health, and logs in view — so you never re-invent a command or lose track of what’s running.

Processes

Start, stop, restart, and inspect dev servers or background commands, with restart policy and readiness checks.

Tests

Run your project’s known validation commands without leaving ADE.

Health

Watch status dots, ports, uptime, and logs per run, with a runtime drawer for proxy and preview info.

​
The welcome screen

On a fresh launch — or whenever no project is open — Run shows the welcome screen: the ADE logo, an Add project button, and your recent projects with their lane counts and last-opened times. Add project opens a chooser to Open an existing folder, Create a new repo (ADE runs git init and writes a starter README and .gitignore), or Clone from a URL or your connected GitHub repos. Click a recent project to jump straight back in.

​
The command grid

Once a project is loaded, Run renders one command card per process your project defines. Each card owns:
  • Name and description from your project config.
  • A lane picker — point the card at any lane to run that process in that lane’s worktree, independent of your global lane selection.
  • Aggregate status — a status dot (stopped, starting/degraded, running, crashed), pid, uptime, listening ports, and a live-run count when several runs are active.
  • Run / Stop — Run always starts a fresh run with its own id; Stop targets the most recent active run.
  • An inline log panel per run, so you drill into a specific run’s output right on the card.
Cards are organized by process groups — a chip row filters the grid, and you can run or stop a whole group at once. A collapsible Advanced drawer surfaces the selected lane’s runtime context: health, preview and proxy info, OAuth callback URL, and port leases.

​
Run it per lane

Because a lane is its own worktree, you can run the same process against several lanes at once — each on its own port — and compare them live. Per-lane port leases and a proxy keep two dev servers from fighting over 3000, and the dashboard fans out across every lane your cards point at.
Group runs are parallel, not ordered: process groups are a filter and a bulk-action key, not a dependency contract. If you need strict start ordering for a bundle, keep those processes on a single lane and use a stack.

​
When agents use Run

Run gives agents the same shared view of what’s running that you have. A chat agent can ask for test output, inspect a failing server’s logs, or start a configured command instead of inventing a new one — and you see the exact managed session it does. Managed processes spawn on whichever machine owns the lane’s worktree, so the agent and the logs stay on the same host.
Typical entries for a JavaScript project — a name on the left, the command on the right:
NameCommand
Web appnpm run dev
APInpm run dev:api
Testsnpm test
Typechecknpm run typecheck
Lintnpm run lint
Each process can also carry a working directory, environment, a restart policy with backoff, a readiness check (a port to wait on or a log pattern to match), and group membership. Definitions are saved to your project config so every lane — and every agent — starts from the same known-good set.
Processes run on your machine (or the lane’s remote host). Review a command before saving it as a shared project default — those defaults are committed and travel to everyone who opens the repo.

Lane runtime

Ports, variables, preview URLs, and startup commands per lane.

Work sessions

How managed processes sit alongside chats, CLIs, and shells.