Satellite AI Agent for VS Code

The Satellite coding agent, working on the folder you already have open.

This is a third host for the agent, not a second implementation of it. The loop, the tools, the planner, the skills, the checkpoints and the compaction all come from backend/src/agent, compiled into this extension at build time — the same modules the cloud server and the desktop app run. A fix to a tool in the backend is a fix here.

VS Code extension host (Node)
  └─ AgentSession implements RunHost          src/session.ts
       └─ driveAgent()                        backend/src/agent/loop.ts
            ├─ tools: read / write / edit / shell / search …
            ├─ skills, sub-agents, checkpoints, auto-verify
            └─ transport ─────────────────► POST /api/agent/inference

Sidebar webview  ⇄  postMessage  ⇄  AgentSession

What it does

• Chat panel in the sidebar — streaming replies, tool cards, plans, clarifying questions, and diffs you can open in VS Code's own diff viewer.
• Sees what you see. Every message carries the file you have open, the lines you have selected, and the errors your language server is currently reporting. That last one is the thing a bare folder cannot offer: the agent gets your real type errors without spending a tool call and half a minute running tsc to rediscover them.
• Edits your workspace directly, with a checkpoint taken before the first change of every message — so "put the files back to how they were when I asked this" is always answerable.
• Rewrite and re-run any earlier message, optionally reverting the files it produced.
• Task history per folder, survives restarts, reopens where it stopped.
• Drives a real browser. Ask it to check the page it just built and it starts your dev server, opens a Chrome window beside the editor and clicks through the page while you watch the cursor move — reading the DOM into numbered refs, reporting the console errors and failed requests each step caused, and handing the keyboard back to you for a login or a CAPTCHA. It is the same driver behaviour as the desktop app's Browser panel, over the DevTools protocol instead of an embedded view.

Commands

Settings

Account and entitlement

Sign-in is email + password, then the six-digit code the backend mails. The session token is kept in VS Code's SecretStorage — Credential Manager on Windows, Keychain on macOS — never in a file.

Access is gated on the same plan.desktopApp entitlement as the desktop app, read from /api/agent/desktop-config. No backend or pricing change was needed to ship this, and no separate plan flag exists: an account that can run the desktop app can run this.

No model key ever reaches this machine. Inference is proxied through the backend, which authenticates the session, enforces the plan's quota and meters the real cost. The status bar mirrors the remaining credit and refuses locally when it is spent — but a local refusal is always re-checked against the server first, so nobody who has just topped up sits blocked by a stale cache.

Development

npm install
npm run build          # or: npm run watch

Then press F5 in VS Code to open an Extension Development Host with the extension loaded.

Verifying

npm run verify         # typecheck → build → activate → drive a real run → drive a real browser

Three checks, all worth knowing about:

• verify:activate loads the built bundle against a stubbed vscode module and activates it. It catches the failures that are expensive to find by hand: a command declared in package.json that nothing registers, a view id mismatch, the agent core throwing at import time, and — deliberately — any network call made during activation while signed out.
• verify:agent drives a real AgentSession against a real temp folder with the real loop and the real write_file tool. Only the model is scripted, by pointing the transport at a local server replaying fixed turns. It is what proves the RunHost wiring is correct end to end, which typechecking cannot.
• verify:browser launches a real Chrome and drives it through the real driver against pages served over real HTTP: 67 assertions covering clicks that actually land, a form submitted with a real Enter, console and network capture, shadow roots and same-origin frames, a covered button that must be refused, and the browser being closed mid-session and relaunched. It asserts the same behaviours as the desktop app's suite, because the two drivers are meant to be indistinguishable to the agent. On a machine with no Chromium it skips rather than fails.

Deliberate limitations

• The browser is a window, not a panel. A VS Code webview is a sandboxed iframe: the extension host cannot inject into it, read its DOM, or send it a trusted input event, so there is nothing in the editor to drive. The agent gets a Chrome of its own instead — launched on demand, in its own profile, driven over the DevTools protocol, with the same cursor and captions the desktop panel draws. On a machine with no Chromium at all, the browser tools are not offered to the model rather than offered and failing.
• Reviews run on the writing model. The inference proxy will only ever honour a request for a cheaper tier than the plan's, never a dearer one, so a local review does not get the stronger reviewer a server-side run would. It is still a second reading in a fresh context, which is where most of its value is.
• First workspace folder only. A multi-root workspace has no single right answer, so the first folder is used and a warning names which one — rather than silently writing into a repository you were not looking at.
• Diffs show hunks, not whole files. A tool reports its patch, not the file, and by the time you click, the file on disk already is the "after" — so the before side is reconstructed from the patch and unchanged regions are elided.