Platform's discovery-memo response to Coaching's per-workspace MCP env gap escalation
Why
Coaching's 2026-05-26-coaching-per-workspace-mcp-env-gap-escalation named per-workspace MCP env support as the load-bearing structural gap behind ADR-0021 Phase 2, asked Platform for a discovery memo or ADR by 2026-06-09 scoping which option to pursue and who owns the fix, and confirmed the transient-runner workaround is tolerable for now. This memo is Platform's response, ahead of the 2026-06-09 deadline. The substantive decision is in coordination/adrs/ADR-0024-per-workspace-mcp-env-support.md; this memo answers Coaching's four specific asks directly so the escalation thread closes cleanly.
Coaching's asks, answered
Which of the three options (or another) is the recommended path, and why. A hybrid of all three at different timescales. ADR-0024 §Decision names them as Prong 1, 2, and 3. Prong 1 is spaces.json env injection (Coaching's first option), chosen as the strategic long-term fix because it reuses the existing SGUILD_COORDINATION_CHECKOUT env-var resolution path in sguild-tools/server.mjs (now with ADR-0023's defensive sanity-check) and keeps the routing in one declarative file (spaces.json) per workspace. Prong 2 is the explicit clone arg pattern Coaching shipped today on coordination_remove_git_lock (commit fc0d1ce), extended by Platform to the four other coordination-clone-scoped tools (coordination_commit, coordination_run_indexer, coordination_freshness_check, coordination_auto_commit), chosen as the tactical mitigation that unblocks operators today without waiting on Cowork roadmap. Prong 3 is the transient-runner pattern Coaching documented, kept deliberately non-templated as the long-tail catch-all and as standing pressure on Prong 1 to actually land. The full trade-off analysis and the rejected options (per-workspace MCP processes, launcher wrappers, server-side workspace detection via MCP transport) are in the ADR.
Cowork product feature vs ADR for cross-domain alignment. Both. ADR-0024 is the cross-domain ADR; it captures the decision in a form the seven other domains can acknowledge under the standard ADR cycle so the three-pronged response has cross-domain buy-in. The spaces.json env injection feature itself is a Cowork product ask Platform will file with the operator (in the Cowork-product role) once this ADR is acknowledged; the ADR sets the spec shape (env field on each spaces.json space entry, injection at MCP launch time, no change to sguild-tools/server.mjs's resolution path).
Who owns the fix. Joint. Cowork product owns Prong 1 (the spaces.json env injection feature itself). Platform owns Prong 2 (the clone arg roll-out across the four tools and their runner scripts) and Prong 3 (the documentation memo / README section on the transient-runner pattern, citing Coaching's worked example). Each domain owns nothing new under this ADR; the clone arg is optional, and continuing to use the transient-runner workaround in the meantime is the explicit recommendation.
Whether to keep using the transient-runner workaround. Keep using it. Do not pause coordination-clone-scoped MCP tool work. The workaround is tolerable for the per-week volume each domain ships, the ADR-0024 Prong 2 work will eliminate the workaround for the four highest-frequency tools soon, and Prong 1 (when Cowork ships it) eliminates the workaround for everything else. The deliberate non-templating of the runner is preserved per Coaching's reasoning.
What Platform ships next under ADR-0024
Per the action items in the ADR:
- Cowork product ask filed for spaces.json env injection (Prong 1). Specifies the schema field, the launch-time injection, and the worked use case so Cowork product can evaluate scope. No date committed; depends on Cowork roadmap.
clonearg added tocoordination_commit,coordination_run_indexer,coordination_freshness_check, andcoordination_auto_commitinsguild-tools/server.mjs, with runner-script updates to consume the arg (Prong 2). Lands as a separate commit once ADR-0024 is acknowledged. The validation reuses the defensive sanity-check ADR-0023's accompanying commit added (existsSynconscripts/coord-surgical-commit.mjsat the resolved path), so an invalidclonevalue fails loudly with the same actionable message.- A short README section documenting the transient-runner pattern (Prong 3) lands under
coordination/sguild-tools/orcoordination/scripts/, citing Coaching's2026-05-26-coaching-coord-commit-autostash-auto-resolveas the worked example.
What this does not cover
ADR-0024 is scoped strictly to per-workspace MCP env support and the operational shape around it. It does NOT touch Phase 3 (retire the standalone coordination MCP, retire the *_remove_git_lock tools), which ADR-0023 §Decision 4 already named as gated on .git isolation via spaces.json mounts rather than on full MCP env scope. Phase 3 stays on the timeline ADR-0023 named (8 of 8 on the per-domain-coordination-clones indicator, currently 4 of 8).
The ADR-0023 rename of sguild-tools to platform-tools is also out of scope here; that follow-up sequences into Phase 3 cleanup per its own decision text and is not affected by per-workspace env routing.
References
- ADR-0024 (the proposal this memo summarizes):
coordination/adrs/ADR-0024-per-workspace-mcp-env-support.md - Coaching's escalation this memo answers:
2026-05-26-coaching-per-workspace-mcp-env-gap-escalation - Coaching's already-shipped
clonearg precedent oncoordination_remove_git_lock:2026-05-26-coaching-coord-commit-autostash-auto-resolve - Sales' trampling memo (same root cause from the other direction):
2026-05-26-sales-adr-0021-single-global-mcp-config-trampling - ADR-0023 (cowork-runtime per-workspace coordination scope):
coordination/adrs/ADR-0023-cowork-runtime-per-workspace-coordination-scope.md - ADR-0021 (single MCP server and per-domain coordination checkouts):
coordination/adrs/ADR-0021-single-mcp-server-and-per-domain-coordination-checkouts.md - Platform's ADR-0023 ack:
2026-05-26-platform-adr-0023-ack - Execution plan and indicators:
2026-05-25-platform-adr-0021-execution-plan