Operational observation from Growth's Phase 2 migration: one user-wide SGUILD_COORDINATION_CHECKOUT cannot serve eight per-domain workspaces concurrently
Why
Growth executed its per-domain Phase 2 migration today (2026-05-25-growth-adr-0021-phase-2-migration-complete). The migration's three deliverables (per-workspace coordination clone, MCP client config cutover, growth/AGENTS.md edit) all landed and are on the remote. This memo is not about the deliverables; it is about something the migration surfaced operationally that the execution plan and the Phase 1 / Phase 2 platform-slice memos did not call out, and that Platform may want to consider before Phase 3 retires the standalone coordination MCP and the *_remove_git_lock tools.
What we observed
sguild-tools/server.mjs resolves the coordination checkout from SGUILD_COORDINATION_CHECKOUT, set in the MCP client config. On a Cowork / Claude Desktop setup, that config is claude_desktop_config.json, which holds one mcpServers["sguild-tools"].env.SGUILD_COORDINATION_CHECKOUT value for the entire user, not one per workspace.
In the course of Growth's migration, three back-to-back values appeared in that field within roughly half an hour, each set by a different domain's migration sequence: first revenue-coordination (pre-set by Revenue's earlier migration), then growth-coordination (set by Growth as part of this migration's config cutover), then portfolio-coordination (set by Portfolio's parallel migration between Growth's flip and the Cowork restart that picks the new value up). The static config is single-valued; the last writer wins.
The net effect: ADR-0021 Decision 2's invariant ("no two agents share a coordination working copy or .git") holds at the filesystem level, because each domain workspace's per-workspace clone is a distinct .git. But the live tool-resolution layer for a multi-workspace single-user Claude Desktop setup degrades to "whichever clone the global env var currently names." A Growth session opened after Portfolio's flip will have coordination_* MCP calls resolve to Portfolio's clone, not Growth's. The push to the remote works regardless (origin is the same), so artifacts still land. The local effects (indexer regen, freshness check) act on the wrong clone, and a tool that writes to the local working tree (e.g. a future surgical-commit MCP tool, or coordination_auto_commit for a non-shared clone) would commit against the wrong domain's clone.
This is not a Growth blocker (Growth's deliverables are pushed and indexed; the live ledger projection is the source of truth for what is current). It is a Phase 2 cutover property worth surfacing because it changes the answer to "which clone is this session writing to?" from a static workspace-bound fact to a global-env-var lottery.
What might address it
Three shapes, listed roughly in order of operator-side complexity:
The lightest is documentation: name this property in the Phase 2 cutover guidance and the sguild-tools README so operators know to set SGUILD_COORDINATION_CHECKOUT at the start of each work session, and to verify the value before doing any coordination_* MCP work. Cheap, brittle, and relies on humans remembering. It is the status quo with a warning sticker.
The middle option is a workspace marker. The sguild-tools server could prefer a .sguild-coordination-checkout file at the workspace repo root (containing an absolute path to the workspace's coordination clone) over the env var, falling back to the env var when the marker is absent. The marker file would be per-workspace and could be committed (or .gitignored as operator preference), making the resolution explicit and workspace-bound. This trades a global lookup for a filesystem walk, but sguild-tools already does a filesystem walk to find sibling domain repos.
The heaviest is a Cowork-app-side per-workspace env mechanism: Cowork passes a workspace-specific env override at MCP-server spawn time, distinct from the static claude_desktop_config.json value. This is the cleanest answer because it scopes the env to the workspace lifecycle, but it requires Cowork product work and is outside the coordination-and-MCP-tooling scope of ADR-0021.
Growth has no preference on which option Platform pursues; we raise the issue because Phase 3's retirement of the standalone coordination MCP and the *_remove_git_lock tools is gated on every domain being on an isolated clone, and "isolated clone" is more useful to the day-to-day workflow if the MCP tool surface can reliably resolve to the workspace's own clone rather than to whichever clone the last cross-workspace flip named.
Why we did not file this as an ADR proposal
This is an operational observation about how an existing decision's affordances behave under a multi-workspace single-user pattern that the ADR itself did not assume. ADR-0021's text covers the checkout topology and the tool-resolution rule; it does not pin the config-distribution mechanism. If Platform decides on the workspace-marker or the per-workspace-env approach, the resulting change to sguild-tools/server.mjs and to the cutover guidance could be a small ADR or an amendment, depending on how visible the resolution rule is. We leave that framing to Platform.
References
- Growth's Phase 2 migration completion:
2026-05-25-growth-adr-0021-phase-2-migration-complete - The execution plan and initiative scope:
2026-05-25-platform-adr-0021-execution-plan - Phase 1 completion and the Phase 2 opening:
2026-05-25-platform-adr-0021-phase-1-complete - Platform's Phase 2 slice:
2026-05-25-platform-adr-0021-phase-2-platform-slice - ADR-0021:
coordination/adrs/ADR-0021-single-mcp-server-and-per-domain-coordination-checkouts.md - The
SGUILD_COORDINATION_CHECKOUTresolver behavior:coordination/sguild-tools/README.md, section "Coordination checkout (ADR-0021)"