Connection registry is process-global: a multi-project server reuses one project's warehouse config (and, since #1204, its resolved store path) for another

[anandgupta42]

Summary

The native connection registry keeps its entire loaded-config state at module scope, with a one-shot loaded latch. In a long-lived server process that handles requests for more than one project directory, the first request's load() wins permanently — every later request for a different project reuses the first project's connection configs and connectors, and never reads the second project's own .altimate-code/connections.json.

If two projects define a connection under the same name (a plausible default such as warehouse or local), project B's sql_execute silently runs against project A's database.

Where

packages/opencode/src/altimate/native/connections/registry.ts:

registry.ts:24  let configs = new Map<string, ConnectionConfig>()
registry.ts:27  const connectors = new Map<string, Connector>()
registry.ts:30  const pending = new Map<string, Promise<Connector>>()
registry.ts:33  let loaded = false

load() (:85-103) clears and repopulates configs from Instance.directory-relative config files, then latches loaded = true at :103. ensureLoaded() (:107) is a no-op once the latch is set. In a server that serves multiple project directories from one process, the first load() result is reused for all subsequent projects — including connection names, credentials, and (see below) resolved absolute store paths.

Pre-existing, but recently made worse

This sharing mechanism is pre-existing — confirmed by diffing origin/main before PR #1204 (commit d9292ecfe7): the identical module-scope configs/connectors/loaded pattern with the identical one-shot latch already existed (keyed off process.cwd() instead of Instance.directory). #1204 did not create it.

What #1204 (merged as 1caa234ff9) changed is the failure mode. Before #1204, a leaked config's relative store path was resolved lazily at connect() time against the then-current process.cwd() — ambiguous, and in a server that never chdirs this usually just errored or opened nothing meaningful. After #1204, resolveStorePaths() (:109-129, called at :175 and :620) pre-resolves and caches an already-absolute store path into configs at first-load time. So the same pre-existing leak now hands project B's request a deterministic absolute path to project A's real store — project B silently reads and writes project A's actual data rather than failing ambiguously.

The leak mechanism is old; the escalation from "fails ambiguously" to "silent cross-project read/write" landed with #1204.

Scope of impact

• Not triggered by normal single-project CLI usage (one process serves one project; the registry only ever holds that project's config).
• Triggered when a long-lived process serves multiple project directories through this registry and same-named connections exist across them.

Minimal fix (needs its own design PR)

Move configs, connectors, pending, and loaded off module scope into InstanceState, keyed by Instance.directory, with connector cleanup wired into the instance finalizer so cached native handles (DuckDB/SQLite file locks, SSH tunnels) are closed when an instance goes away rather than leaking for the process lifetime. ensureLoaded() / load() / get() / list() / test() / add() / remove() / reload() / reset() all need to read/write the current instance's slice rather than the shared module map — a real refactor, not a patch.

Citations

registry.ts:24,27,30,33 (module state), :69-75 (projectRoot()), :85-103 (load()), :107 (ensureLoaded()), :109-129 (resolveStorePaths()), :175 and :620 (call sites).

Surfaced by review threads on #1204 (cubic + codex + coderabbitai all flagged the same pattern, "make registry state instance-scoped"). #1204 merged before these were addressed; this issue tracks the follow-up.