feat: add --agents to run Code's agent host

[1000ch]

What

Adds --agents, which starts Code's agent host so agent sessions can run on the server.

Why

VS Code 1.132 added the Agents Window, opened on the desktop with code --agents. code-server cannot serve that window yet, but the piece underneath it — the agent host — already ships in the server build and is simply never started.

Three facts from the submodule at df53daa (1.132.0), all still true on main (1.134.0):

1. The Agents Window workbench is vs/sessions, a layer parallel to vs/workbench. A web build of it exists (vs/sessions/sessions.web.main.internal.ts), but build/gulpfile.reh.ts lists only buildfile.codeWeb in webEntryPoints, so vscode-reh-web — the build we package — has no Agents Window bundle. Only gulpfile.vscode.web.ts (the vscode-web build behind vscode.dev) includes buildfile.sessionsWeb.
2. The agent host itself is in our build: buildfile.codeServer includes vs/platform/agentHost/node/agentHostMain, and both reh and reh-web use it.
3. serverServices.ts spawns the agent host only when --agent-host-port or --agent-host-path is set, and registers the agentHostProxy IPC channel at the same time. With neither flag it registers UnavailableAgentHostChannel and logs no --agent-host-bridge-port / --agent-host-bridge-path set.

The browser side is already wired up. workbench.web.main.ts registers EditorRemoteAgentHostServiceClient for IAgentHostService, which proxies the agent host protocol over the remote agent connection, and WebAgentHostEnablementService treats the agent host as available whenever there is a remote authority — which for code-server is always. So the workbench believes agent sessions are available and then has nothing to connect to.

This is the same topology Code already uses for tunnels. From serverServices.ts:

the caller (the CLI code tunnel flow) is expected to capture the bound port from the AH's readiness line and pass it back as --agent-host-bridge-port on the renderer-serving servers

A browser renderer talking to an agent host over the remote connection is an intended configuration; nobody has connected the self-hosted server to it.

How

--agents makes toCodeArgs pass agent-host-path pointing at agent-host.sock in the user data directory (a named pipe on Windows, which has no Unix sockets). That is enough for Code to spawn the agent host and register the channel the browser uses.

Code binds the socket but never unlinks it, so a socket left behind by a killed instance would make the agent host fail to listen on the next start. code-server removes a stale one before Code can load.

Named after Code's own flag so the two line up if we can serve the Agents Window later.

Limitations

• No Agents Window. Agent sessions surface in the regular chat UI. Serving the real window needs buildfile.sessionsWeb added to the reh-web entry points, plus an HTML entry point and a route to serve it — a patch against lib/vscode, which this PR deliberately does not add.
• Claude and Codex agents are unavailable. Code resolves their SDKs from product.agentSdks, and its build pipeline stamps that only into reh, not reh-web ("REH-web skips it because the agent host is node-only", AH: per-platform agent SDK build + CDN upload microsoft/vscode#321012). Pointing Code at a local SDK root via its dev-override env vars is the only way around it today.
• Socket permissions. Anyone who can read the socket can talk to the agent host. It lives in the user data directory and is not exposed over HTTP.
• The Agents Window is a Preview feature upstream.

Testing

• npm run test:unit — added coverage for parsing --agents and for the agent-host-path that toCodeArgs produces, including that concurrent instances get separate sockets.
• Not verified at runtime. I could not build lib/vscode in this environment, so the agent host actually spawning and a session connecting through it has not been exercised. Happy to hold this until someone can confirm on a real build.

🤖 Generated with Claude Code