dev3000

d3k

d3k gives your coding agent a managed browser and a shared timeline of server output, browser console messages, exceptions, network requests, and interactions.

Install the skill, then ask your agent to run the project, reproduce an issue, and inspect what happened:

pnpm dlx skills add vercel-labs/dev3000 --skill d3k

Use d3k to run this project and help me debug the checkout flow.

The skill owns a small background JavaScript runtime. No global d3k binary is required. Node.js 24+, pnpm, and Chrome are needed. The installed local skill runs under Node; repository development and the sandbox launcher also require Bun.

Try the source

Until this runtime is released, use the helper from this checkout. Run these commands from the app you want to debug, replacing /path/to/dev3000 with this checkout:

node /path/to/dev3000/skills/d3k/scripts/runtime.mjs portless status
# One-time administrator authorization, if setup is required:
node /path/to/dev3000/skills/d3k/scripts/runtime.mjs portless setup
node /path/to/dev3000/skills/d3k/scripts/runtime.mjs start

Keep start in a retained background process session. The helper runs checkout source with Bun. An installed skill can target this source by setting D3K_RUNTIME_ROOT=/path/to/dev3000.

Canonical Portless HTTPS must be ready before starting the server or browser. The runtime uses a port-free URL such as https://my-app.localhost, with a project-stable Chrome profile for authentication. It fails before launching the app if setup is incomplete.

Read evidence

d3k, dev3000, and d3k-runtime expose the same commands. The examples below use d3k. In a checkout, substitute node /path/to/dev3000/skills/d3k/scripts/runtime.mjs.

d3k status
d3k browser snapshot -i
d3k browser click @e2
d3k events --session <sessionId> --after <cursor>
d3k events --after <cursor> --source server
d3k events --after <cursor> --level error
d3k logs -n 100 --type browser
d3k errors --context --json
d3k stop

Before reproducing an issue, retain the sessionId and cursor from status. Read events after that cursor, continuing while hasMore is true. A new session returns reset: true; dropped reports events evicted from the buffer. Filtered queries advance through examined events, so keep the original cursor when comparing multiple views of an interval.

Server and browser events share sequence numbers assigned at collection time. Network events retain CDP request IDs, and exceptions retain stack traces. Chronological proximity to a server line does not establish causation.

The timeline holds at most 5,000 events or 8 MiB. Individual records are capped. No log files are written by the runtime, and its evidence disappears on exit.

Network evidence includes redacted request/response headers (including wire-header events), protocol/cache metadata, encoded transfer size, raw CDP response timing, and DNS/connect/TLS/send/TTFB/download/total durations in milliseconds when available.

Request and response body previews capture app-origin Fetch/XHR JSON and URL-encoded forms, redact common credential fields recursively, and retain up to 8 KiB per preview. Bodies over 64 KiB, unsupported formats (including binary and streaming responses), and cross-origin bodies are omitted; completed API requests report an omission reason when capture is unavailable. Response bodies arrive as separate response-body events after completion, so continue reading the timeline after the request finishes.

URL query values, authorization/cookie headers, and common credential fields are redacted; this is best-effort redaction, and application payloads, console output, and server messages can still contain sensitive data.

Only browser profile and session discovery data persist under ~/.d3k/<project>/. Local control uses authenticated IPC, not an HTTP listener on the network. Automatic screenshots are off; use browser screenshot <absolute-path> when needed.

Server and browser ownership

The runtime detects the project's package manager and dev script. Use start --command '<dev command>' for other projects or custom servers. Use --headless for CI and --servers-only when browser monitoring is intentionally unwanted.

Chrome's sandbox stays enabled in both headed and headless modes. If a constrained container cannot support Chrome sandboxing, explicitly set D3K_CHROME_NO_SANDBOX=1 when starting the runtime. This disables browser isolation and emits a startup warning; use it only in an appropriately isolated environment. d3k does not retry without the sandbox automatically.

The agent and user share the same monitored browser. Do not launch a second server or substitute another browser profile during a session. Leave the runtime running when handing the browser to the user for testing.

Start local sessions with d3k start. Both timeout flags use milliseconds: --startup-timeout defaults to 120000 and --browser-navigation-timeout to 30000. Local startup also supports --browser <path>, --profile-dir <dir>, and --debug. Browser options cannot be combined with --servers-only.

logs shows recent retained events; errors filters errors and --context includes up to five preceding events per error. Both accept --count 1..500 and --json; JSON includes cursor and evidence-gap metadata. Use cursor-based events for incremental reads. No command recovers evidence from a stopped session.

Upgrade explicitly with d3k upgrade (global Bun install), or update through your package manager. Startup never upgrades the package or installs skills.

Remote project, local Chrome

Run this from any directory; the project repository never needs to exist on your laptop:

vercel login
d3k --project my-team/my-project --name my-dev
# The terminal enters the remote project directory. Then:
fx

This command needs a recent Vercel CLI (tested with 59.26.0), Bun, Node.js 24+, macOS, and access to Vercel Sandbox. It uses your installed Google Chrome binary with a dedicated per-project profile; Chrome updates remain managed by your existing installation or IT. d3k does not download another browser. Run it from any directory: no local project checkout is needed. It uses your Vercel login to resolve the linked GitHub repository, project root, Development environment, and install/dev commands. It clones and installs the project remotely, uploads the installed d3k distribution, launches the dev server, opens a dedicated local Chrome, and enters the sandbox shell. d3k sandbox --project my-project --scope my-team is equivalent.

The shell starts in the Vercel project's root. d3k uses the image's fx binary or installs it from fx.sh when absent. fx connects automatically to the selected project’s team AI Gateway using a project-scoped session key. The key expires automatically after --timeout minutes (default: 60) and has a $5 non-renewing spending limit including BYOK usage. d3k prints the expiration time when the session closes. Resume creates a fresh key. Use --gateway-budget 20 to change the session limit, --gateway-budget none to remove it, or --no-gateway for manual authentication. Automatic setup requires permission to create team Gateway API keys and does not bypass team model or provider restrictions. Project processes and harnesses share the sandbox identity, so use projects you trust with that limited Gateway access. d3k does not forward laptop harness credentials or Vercel management tokens. Use --no-fx to skip installation. App environment variables are supplied to dependency installation and the dev runtime; the interactive harness shell does not automatically inherit them.

Sandbox mode currently requires macOS. Chrome runs under an OS filesystem policy that permits its application bundle, system libraries, and dedicated d3k profile and temporary files. Other laptop files are denied, including CDP navigation and uploads. Host clipboard access is blocked at the OS pasteboard service. Chrome's inner sandbox cannot nest inside this macOS policy; the outer policy applies to the browser and all its children. Cookies use the dedicated profile’s local storage instead of the laptop keychain. A sandbox session can read and modify its own browser profile and authenticated web sessions. Use sandbox mode with projects you trust with that session's browser access. Other operating systems fail closed until equivalent confinement is available.

Remote harness context includes the laptop browser's existing CDP bridge, project directory, and exact d3k-runtime browser commands. Sandbox fx automatically loads the connected-session skill from a temporary block in its own ~/.fx/AGENTS.md at startup, including when launched manually from the shell. Existing instructions are preserved, and the block is removed on exit; repository instruction files are untouched.

The launcher supplies project-scoped CLI authentication to the interactive connection without forwarding that management token into the VM. Inside the remote project directory, use the existing runtime:

d3k status
d3k browser snapshot -i
d3k events --level error

Development environment values pass through launcher memory into the sandbox; d3k does not save a local env file or project checkout. The laptop keeps d3k, its browser profile, and session metadata. Other agents require their own authentication. Automatic creation supports public GitHub repositories and private repositories already onboarded to Vercel managed Sandbox Git. d3k detects an existing git:write Bound for the exact linked repository and requests brokered credentials using your configured Git name and email. The project must have the Sandbox Git credentials and signed-commits flags enabled and the Vercel GitHub App installed. The current platform warm-pool workaround requires six vCPUs for these sessions; effective team limits must permit that shape. d3k does not change authorization policies or copy laptop GitHub credentials into the VM. --attach my-dev remains available for a provisioned sandbox. Private package registry authentication also requires separate provisioning. The sandbox CLI reserves port 3000 for the app and exposes its authenticated proxy on a separate infrastructure port, so project startup checks do not mistake d3k for an existing dev server.

Project dependencies use the repository's package manager: packageManager takes precedence, followed by Bun, pnpm, Yarn, or npm lockfiles (npm is used when none is identified). Workspace installs run from the directory declaring that manager or containing its lockfile. Conflicting lockfiles require a packageManager declaration or an explicit command. A CLI --install-command overrides the Vercel project install setting; either explicit command runs from the project directory.

Use --branch feature, --command 'pnpm run dev', or --install-command 'pnpm install' to override project defaults. Dev commands must honor PORT, which identifies the private upstream port. --no-shell retains the local browser companion without opening a shell; --headless runs local Chrome headlessly. Sandbox compute and Gateway keys both default to a 60-minute lifetime; --timeout <minutes> changes both equally. Exiting stops the runtime and any sandbox created by this invocation, preserving its filesystem for --attach <name>. An attached sandbox stays running when the companion exits. Closing the dedicated Chrome also ends the session.