feat(electron): give the bridged coding agent xNet's workspace tools

[crs48]

What was broken

The desktop app already ran an agent bridge that drives your own claude CLI as the chat model. But the agent had no path to your data.

The MCP wiring sat behind XNET_BRIDGE_MCP + XNET_BRIDGE_MCP_CLI, and the CLI entry pointed at xnet mcp serve — except @xnetjs/cli is not an Electron dependency, so that path could never resolve in a packaged app. Even had it resolved, it passed no token, so the local API would have returned 401. Chat could talk about your workspace but not read or write it.

What this does

Hosts the MCP server in the Electron main process, over the renderer store proxy, and points the agent at it over Streamable HTTP on an ephemeral loopback port. No CLI to spawn, no local-API hop, no per-session token to plumb across processes. Withhold the tools with XNET_BRIDGE_MCP=0.

Also replaces the local API's hardcoded four-schema stub (Schema/Task/Project/Note) with the renderer's real schemaRegistry, served over the same IPC channel that already carries store operations. Anything reading that stub was getting a fiction.

A subtlety worth reviewing

getAllIRIs() is synchronous in SchemaRegistryAPI, but the registry lives an IPC hop away in the renderer — so the proxy caches it. Both subscribers start before createWindow(), so priming must be background-with-retry and must never be awaited at boot; awaiting it deadlocks startup (hit and backed out during development). While unprimed it throws rather than returning [], so "renderer not ready" cannot read as "this workspace has no schemas".

Verification

Verified in the live desktop app over CDP, not just unit-tested.

Bridge status from inside the renderer:

{ running: true, agent: "claude", url: "http://127.0.0.1:31416", workspaceTools: true }

The spawned process, wired as designed:

claude -p "..." --output-format stream-json --include-partial-messages --verbose
  --mcp-config "~/Library/Application Support/xnet-desktop/agent-bridge-mcp.json"
  --allowedTools mcp__xnet__*

A real chat turn through the bridge returned "Schema count: 194 · New page ID: M6_jJ2XVxc5aKIx45SX3V", and the page was really in the store:

{ id: "M6_jJ2XVxc5aKIx45SX3V", schemaId: "xnet://xnet.fyi/Page@1.0.0",
  title: "Agent Smoke Test 0406" }
pageCount: 29 -> 30

194 schemas is the proof the registry fix works — the old stub would have reported 4. The test page was deleted afterwards.

Also confirmed empirically: createMcpHttpServer answers POST with plain application/json (no SSE, no mcp-session-id), and Claude Code 2.1.220 accepts it as a {"type":"http"} MCP server. That was the load-bearing unknown in this design, so it was probed against the real CLI before building on it.

Checks: turbo typecheck clean, 146 electron + 166 devkit tests green (6 new covering the priming logic), lint 0 errors.

Notes

• The xnet_query schemaId bug found while verifying this landed separately in fix(plugins): honour schemaId in xnet_query and xnet_create #637.
• Changeset included (@xnetjs/devkit minor — new mcpHttpConfigFor export) plus a changelog fragment.

🤖 Generated with Claude Code

[github-actions]

🖼️ UI changes in this PR

No visual differences detected in the changed UI.

_{CI run}

[github-actions]

Preview removed for PR #638.