CtrlK
BlogDocsLog inGet started
Tessl Logo

vscode-dev-workbench

Use when the user wants to run the vscode.dev server locally and exercise the VS Code workbench or Agents window in the integrated browser against the local `microsoft/vscode` sources. Covers starting the dev server, the `vscode-quality=dev` URL, browser-driven interaction patterns, and optionally wiring up a local mock agent host for the Agents window.

72

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Running vscode.dev Against Local VS Code Sources

The vscode-dev repo is the vscode.dev server. When run locally with ?vscode-quality=dev, it serves the VS Code web workbench (or Agents window at /agents) from the sibling microsoft/vscode checkout. This is the fastest way to validate web-only changes to the workbench without shipping an Insiders build.

Layout assumption

vscode-dev and vscode must be sibling folders:

<workRoot>/
  vscode/          # microsoft/vscode checkout
  vscode-dev/      # microsoft/vscode-dev checkout

If your paths differ, check server/ in vscode-dev for the source root resolution — the /vscode-sources/* route maps to ../vscode.

Start the dev server

Critical: Run npm run dev from the vscode-dev folder, NOT from vscode. The vscode repo has no dev script and will fail with npm error Missing script: "dev". Terminal tools that simplify/strip leading cd into separate commands will silently keep the cwd of a previous terminal — always use an absolute pushd or verify with pwd before npm run dev.

cd /path/to/vscode-dev     # NOT /path/to/vscode
npm run dev                # runs watch + nodemon; serves https://127.0.0.1:3000

If you're driving this through an agent/terminal tool, prefer:

pushd /absolute/path/to/vscode-dev >/dev/null && pwd && npm run dev

On first start you may see one crash like Cannot find module './indexes' — it's the watcher racing the first build. nodemon restarts automatically once out/ finishes compiling. The server is ready when curl -sk -o /dev/null -w "%{http_code}" https://127.0.0.1:3000/ returns 200.

URLs

  • https://127.0.0.1:3000/?vscode-quality=dev — main workbench, local dev sources
  • https://127.0.0.1:3000/agents?vscode-quality=dev — Agents window, local dev sources
  • https://127.0.0.1:3000/?vscode-version=<commit> — pinned production commit
  • Add &vscode-log=trace for verbose client logging

Interacting via the integrated browser

Use open_browser_page and the standard browser tools.

Enter inserts a newline in the chat input

The chat input is a Monaco editor — page.keyboard.press('Enter') inserts a newline. To send, click the Send button (a[aria-label^="Send"]) or use the send keybinding.

Hard-reloading after a rebuild

The service worker caches client assets aggressively. A plain reload can still serve stale modules:

await page.evaluate(async () => {
  const regs = await navigator.serviceWorker?.getRegistrations() ?? [];
  await Promise.all(regs.map(r => r.unregister()));
  const keys = await caches?.keys() ?? [];
  await Promise.all(keys.map(k => caches.delete(k)));
});
await page.reload({ waitUntil: 'domcontentloaded' });

Simulating mobile (only when explicitly requested)

The integrated browser panel clamps width, so page.setViewportSize() and CDP setDeviceMetricsOverride narrow the viewport only as far as the panel allows. User-Agent override and touch emulation work fine:

const client = await page.context().newCDPSession(page);
await client.send('Emulation.setUserAgentOverride', {
  userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Mobile/15E148 Safari/604.1',
  platform: 'iPhone'
});
await client.send('Emulation.setTouchEmulationEnabled', { enabled: true, maxTouchPoints: 5 });
await client.send('Emulation.setDeviceMetricsOverride', {
  width: 393, height: 852, deviceScaleFactor: 3, mobile: true,
  screenOrientation: { type: 'portraitPrimary', angle: 0 }
});
await page.reload();

For a true mobile viewport, drive a standalone Playwright script with devices['iPhone 14 Pro'] instead of the integrated browser. If a mobile-responsive overlay intercepts pointer events during automation, fall back to { force: true } on click().

Known-noise console messages (ignore)

  • Canceled: Canceled at clipboardService.js — cancelled permission probes on hover.
  • NotAllowedError: Failed to execute 'write' on 'Clipboard' — web clipboard requires a user gesture.
  • [WebTunnelAgentHost] Failed to list tunnels — only fires when not signed in.
  • The web worker extension host is started in a same-origin iframe! — expected in dev.
  • Unrecognized feature: 'local-network-access' — dev manifest warning.
  • [LEAKED DISPOSABLE] stacks — GC-based tracker; only real if reproducible across reloads.

Troubleshooting

SymptomCauseFix
Cannot find module './indexes' on first runnodemon started before TS compile finishedWait; it auto-restarts
Session not found: <uuid> when sending chatReopened a cloud/tunnel-backed sessionStart a fresh session (⌘N) in the Agents window
Workspace picker opens native dialog and hangs automationSelect Folder… needs a real file dialogPick a workspace URL scheme instead, or skip in automation
Stale UI after editing vscode/ sourcesService worker cacheUnregister SWs + clear caches (snippet above)

Testing the Agents window against a local mock agent host

If the scenario touches the Agents window (/agents route), you almost always need the mock agent host running. Without it, the Agents window will sit on the sign-in / tunnel-discovery screen and block any real interaction. Start it in addition to the dev server — it's a second terminal, not a replacement.

vscode-dev supports a ?mock-agent-host=ws://… URL parameter that short-circuits tunnel discovery and wires the Agents window to a raw WebSocket. Pair it with the mock agent host binary from microsoft/vscode:

cd /path/to/vscode
node out/vs/platform/agentHost/node/agentHostServerMain.js \
  --enable-mock-agent --quiet --without-connection-token --port 8765
# Listens on ws://localhost:8765

Prerequisite: out/ in the vscode repo must be populated by the VS Code - Build task (or npm run watch). If out/vs/platform/agentHost/node/agentHostServerMain.js is missing, start that task first.

--enable-mock-agent registers the ScriptedMockAgent from src/vs/platform/agentHost/test/node/mockAgent.ts with one pre-existing session. Seed additional sessions via the VSCODE_AGENT_HOST_MOCK_SEED_SESSIONS env var, using a comma-separated list of session URIs (for example, VSCODE_AGENT_HOST_MOCK_SEED_SESSIONS=mock://pre-1,mock://pre-2). Scripted prompts include hello, use-tool, error, permission, write-file, run-safe-command, slow, client-tool, subagent, etc. (see mockAgent.ts for the full list).

Then open:

https://127.0.0.1:3000/agents?vscode-quality=dev&mock-agent-host=ws://localhost:8765&vscode-log=trace

Expect these logs in order:

  • [MockAgentHost] Using local mock agent host at ws://localhost:8765/
  • [WebTunnelAgentHost] Found 1 tunnel(s) with agent host support
  • [WebTunnelAgentHost] Connecting to tunnel 'mock-agent-host' (mock)
  • [WebTunnelAgentHost] Protocol handshake completed with tunnel:mock
  • [RemoteAgentHost] Registered agent mock from tunnel:mock as remote-tunnel__mock-mock

This bypasses GitHub auth and the /agents/api/hosts endpoint entirely, so it works offline. The fake tunnel on the vscode-dev side must advertise a protocolvN tag ≥ TUNNEL_MIN_PROTOCOL_VERSION in src/vs/platform/agentHost/common/tunnelAgentHost.ts (currently 5); otherwise WebTunnelAgentHostService filters it out and you'll see Found 0 tunnel(s) with agent host support.

Repository
posit-dev/positron
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.