dev3000 (d3k): an agent-first debugging runtime that owns your dev server and browser

The problem d3k solves: agents debug from disconnected snapshots

A coding agent asked to fix a broken checkout flow usually gets two partial views. It can read terminal output from a dev server it did not start, and it can look at a browser it did not launch. Nothing ties the two together, so the agent reasons about an error without knowing which click, navigation or request produced it. The README frames d3k as an answer to exactly that: a runtime that starts your dev server, opens a monitored browser with a project-stable Chrome profile, and produces one timeline of server logs, browser errors, network activity, interactions and screenshots.

The audience is narrow and specific. This is for people who already delegate work to a coding agent and want the agent to own the runtime rather than guess at it. The README describes the primary interface as the d3k skill, with example prompts like "Debug the checkout flow with d3k." The interactive terminal dashboard still exists, but the README states it is not required for the agent workflow. That ordering is the design statement: the human-facing TUI is now the secondary path.

One consequence is worth stating plainly. d3k is the dev-server owner for the session, and the README tells you not to run `npm run dev` or `bun run dev` alongside it. This is not a passive observer you can bolt onto an existing setup. Adopting it means changing who starts your app.

How the runtime works: Portless URL, managed Chrome profile, unified log

Three mechanisms carry the design. The first is Portless. Every app gets a stable port-free HTTPS URL by default, such as `https://my-app.localhost`, so browser state and callbacks do not move when the underlying development port changes. `d3k portless setup` performs one-time administrator authorization to generate and trust a local HTTPS CA and install a root-owned startup service on port 443. After that, every d3k server registers behind that proxy and the managed browser opens the Portless URL. The README is explicit that d3k fails before starting the app when canonical Portless is unavailable, and that `--no-portless` is only for cases where direct localhost routing is specifically required.

The second is the persistent browser profile. Each project gets a Chrome profile under `~/.d3k/<project>/chrome-profile/`, so login state, cookies and local storage survive across debugging sessions. The README warns that a separate Playwright, browser MCP, raw Chrome or custom `agent-browser --profile` session is a different browser identity and can break sign-in flows. That warning is the sharpest architectural claim on the page: identity continuity across sessions is treated as a correctness property, not a convenience.

The third is the artifact layout. A session manifest sits at `~/.d3k/<project>/session.json` and is discoverable with `d3k status --json`. The consolidated log is at `~/.d3k/<project>/d3k.log` or under `logs/`, screenshots under `~/.d3k/<project>/screenshots/`, and the Chrome profile under `~/.d3k/<project>/chrome-profile/`. Crash output goes to `~/.d3k/crash.log`. Everything lives per project under one directory, which is what makes the feed joinable: server output, console messages, network requests, interactions and screenshots all land in the same session scope.

Installing d3k and running a first debugging session

Node.js 24 or newer is required. Install the runtime globally with bun, or with npm if you prefer. Both commands are given in the README.

bun install -g dev3000

npm install -g dev3000

Next, install the d3k skill for your coding agents. The README uses a wildcard agent selector and global scope, so the skill is available to whichever agent you run.

bunx skills add vercel-labs/dev3000 --skill d3k --agent '*' -g -y

Before starting anything, check whether the project's runtime and the canonical Portless HTTPS endpoint are ready. The README's agent workflow begins with exactly these two calls.

d3k portless status --json
d3k status --json

If Portless reports that setup is required, complete it. The README describes this as one-time administrator authorization. Then start the runtime in agent-safe mode. The `-t` flag streams the consolidated log, and the README notes that non-TUI is the default in this mode.

d3k -t

The README says to wait until d3k reports a port-free HTTPS URL and a managed browser. After you reproduce the bug, inspect the evidence rather than scrolling raw output. `d3k errors --context` is the README's recommended first read, and `d3k logs -n 200` gives the tail of the consolidated log. You can narrow by source with `d3k logs --type browser` or `d3k logs --type server`.

d3k errors --context
d3k logs -n 200
d3k logs --type browser

If your agent needs to drive the monitored browser instead of handing it to you, the README lists `d3k agent-browser snapshot -i`, then `click @e2` and `fill @e3 "text"` against the snapshot's element references. The distinction the README draws is between "let me test", where the agent prepares the headed browser and waits while you reproduce, and "test this", where the agent drives and investigates on its own.

Where d3k gets in the way

The Portless requirement is the largest constraint, and the README does not soften it. Setup needs administrator authorization to create and trust a local HTTPS CA and to install a root-owned service on port 443. On a managed laptop, a locked-down CI image, or a machine where port 443 is already claimed, that step is the whole project. The fallback exists (`--no-portless`), but the README scopes it to cases where direct localhost routing is specifically required, which means you lose the stable URL that keeps browser state and callbacks from moving when the port changes.

The second constraint is ownership. Because d3k starts the dev server, it does not compose with a workflow where you already run `npm run dev` in one terminal and want monitoring on top. The README states the rule directly rather than offering a mode for it.

The third is that the documented agent workflow is a sequence of steps the agent is supposed to follow: check Portless, check status, start `d3k -t` in a retained background session, wait for the URL, then read errors. That is a lot of protocol resting on the skill teaching the agent correctly. The README does not document what happens when an agent skips a step, starts a second runtime, or loses the background session. If you want a single command that either works or fails loudly, this is more moving parts than you asked for. The README also does not document rollback or uninstall steps for the Portless CA and startup service, so treat that as something to work out before you run setup on a machine you care about.

d3k versus Playwright and browser MCP servers

The closest alternative is a browser automation library such as Playwright, or a browser MCP server, paired with your own dev server. The difference is not capability, it is who owns the process and which browser identity is in play. With Playwright you write the script that navigates and asserts; the browser is a fresh context you construct, and correlating a console error with the server log line that caused it is your job. With d3k the browser is launched by the runtime, the profile persists per project under `~/.d3k/<project>/chrome-profile/`, and the server output is captured by the same process that owns the browser.

That ownership is what makes the unified feed possible, and it is also what the README warns about. It explicitly says a separate Playwright session is a different browser identity and can break sign-in flows. So the trade is concrete: if your debugging depends on authenticated state, d3k's managed browser is the point, and bolting Playwright on beside it works against you. If your debugging is a scripted assertion suite that runs headless in CI, d3k's `--headless` flag exists but the persistent-profile and stable-URL machinery buys you less, and a plain Playwright setup is a smaller dependency.

For teams that just want terminal output plus browser console in one pane, the standalone TUI is the relevant comparison, not another tool. The README notes `d3k` alone gives the interactive dashboard, and that `d3k --with-agent claude`, `--with-agent codex` or `--with-agent opencode` splits the screen in tmux. That split-screen workflow requires tmux; the background agent workflow does not.

Maintenance, versions and what the MIT licence leaves open

The repository is not archived, and the last push was on 2026-09-14. The most recent release is v0.0.180, dated 2026-09-14, following v0.0.178 on 2026-07-09 and v0.0.177 on 2026-06-19. The version in the repository's package.json is 0.0.181-canary. A 0.0.x line with three releases across roughly three months tells you the surface is still moving, and the canary version in the manifest suggests changes land between tagged releases. If you pin a version, expect to re-read the option table when you upgrade rather than assuming flags are stable.

The licence is MIT, which is permissive and imposes no source-disclosure obligation on your own code. That is the end of what the README supports. The README does not describe what the Portless setup writes to your system beyond a local HTTPS CA and a root-owned startup service on port 443, and it does not document an uninstall path. Those are system-level changes, so check them against your own machine policy before running setup; nothing here is legal advice, and the operational question of what a root-owned service on 443 means for your environment is yours to answer.

Upgrade cost is mostly the runtime plus the skill. The README's development section uses d3k itself as the local runtime (`d3k -t`), then `bun run lint` and `bun run typecheck` after changes, with `bun run canary` for CLI or TUI changes under `src/`. That is the project's own workflow, not a requirement for consumers, but it does show the runtime is expected to survive its own use.

Editorial conclusion

Adopt d3k if you hand debugging work to a coding agent and want one stable URL, one persistent Chrome profile and one evidence stream instead of a terminal full of separate tools. Skip it if you only want a log viewer, if you cannot grant one-time administrator authorization for the Portless CA and the port 443 startup service, or if your workflow depends on a separate Playwright or browser MCP session for auth-sensitive flows. Before committing, verify three things yourself: that `d3k portless status --json` reports canonical HTTPS ready, that the project's dev script is detected without `-s` or `-c`, and that a login flow still completes in the managed browser rather than a second browser identity.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vercel-labs/dev3000 on GitHub