Describe the enhancement you want to request
Integrations in a workspace are served by the local datamate engine — the same process the VS Code extension spawns as datamate start-stdio. A terminal Altimate Code session in a project bound to a workspace cannot acquire that engine on its own.
Today it can only reuse an MCP entry an IDE already wrote. With no entry present, it falls through to the hosted SSE endpoint, which runs in multi-user mode and serves a different tool set — no connection validation, no extension-bridge tools, and a server-side cwd. So a terminal session in a bound project ends up with either the IDE's tools (if an IDE happens to be running) or the wrong ones, and nothing says which.
Two further gaps make this hard to notice:
- Silent under-delivery. The engine intersects the workspace's declared allowlist with what it actually managed to build and reports nothing about the difference. A workspace declaring 52 tool keys can deliver 12 with no indication that 40 are missing or why.
- Tools that cannot work on the CLI are still offered.
datamate_manager list-integrations lists extension-type integrations, which are RPC into a live VS Code host and have no meaning from a terminal.
What it should do instead
- Reuse a connected
datamate entry when one exists; when the entry is down, distinguish a URL entry (an IDE's in-process engine or the hosted endpoint — not revivable from here) from a failed command entry (retry once, never double-spawn).
- Where a suitable
datamate is already on PATH, spawn it for the bound workspace and persist it to the project config. A lookup, never an install — the CLI ships as a self-contained binary with no Node runtime and must not pull one in.
- With no engine present, say which workspace tools are unavailable and how to install one.
- Never fall back to the hosted endpoint on failure: the two tool sets diverge in both directions, so a silent fallback changes the workspace's declared contract. Report the failure instead.
- Surface the declared-vs-delivered gap.
- Have the engine's tools available on the first turn of a session, not the second.
Should be inert for unbound projects and gated on the workspace pilot flag.
Describe the enhancement you want to request
Integrations in a workspace are served by the local datamate engine — the same process the VS Code extension spawns as
datamate start-stdio. A terminal Altimate Code session in a project bound to a workspace cannot acquire that engine on its own.Today it can only reuse an MCP entry an IDE already wrote. With no entry present, it falls through to the hosted SSE endpoint, which runs in multi-user mode and serves a different tool set — no connection validation, no extension-bridge tools, and a server-side cwd. So a terminal session in a bound project ends up with either the IDE's tools (if an IDE happens to be running) or the wrong ones, and nothing says which.
Two further gaps make this hard to notice:
datamate_manager list-integrationslists extension-type integrations, which are RPC into a live VS Code host and have no meaning from a terminal.What it should do instead
datamateentry when one exists; when the entry is down, distinguish a URL entry (an IDE's in-process engine or the hosted endpoint — not revivable from here) from a failed command entry (retry once, never double-spawn).datamateis already onPATH, spawn it for the bound workspace and persist it to the project config. A lookup, never an install — the CLI ships as a self-contained binary with no Node runtime and must not pull one in.Should be inert for unbound projects and gated on the workspace pilot flag.