agentleFS
OpenCortexIDEOpenCortexIDE/cortexide/.github/skills/vscode-dev-workbench/SKILL.md

vscode-dev-workbench

Skill175 starsChanged 8 months agoMITView on GitHub

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.

5 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

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

    line 20
  2. Distinctive:

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

    line 31
  3. Very specific:

    Add &vscode-log=trace for verbose client logging

    line 44
  4. Very specific:

    Use open_browser_page and the standard browser tools.

    line 48

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.