amacocianandCopilot
d9ecb908b8
Charlie/project-charlie: Build image / config (push) Successful in 1s
Charlie/project-charlie: Build image / build (push) Skipped
Charlie/project-charlie: Deploy runners / config (push) Successful in 2s
Charlie/project-charlie: Deploy runners / deploy-morgott (push) Skipped
Charlie/project-charlie: Deploy runners / deploy-melina (push) Skipped
Charlie/project-charlie: Deploy stack / config (push) Successful in 1s
Charlie/project-charlie: Deploy stack / deploy (push) Skipped
Release / release (push) Successful in 21s
Backends grow from "flag + env scrub" to four knobs — render, mcpArgs,
mcpEnv, forbidEnv — so a CLI can receive sherlock's MCP servers however
it accepts them, without ever editing the operator's own config:
- codex: repeated `-c mcp_servers.<name>....` TOML overrides, which
layer over ~/.codex/config.toml. $CODEX_HOME is avoided on
purpose: it also holds auth.json.
- opencode: $OPENCODE_CONFIG pointing at a rendered file in opencode's
own schema; it is one layer of that CLI's config merge.
- goose: repeated `--with-extension <name>:<env> <command line>`.
Those belong to a subcommand, so MCP flags are appended
after the operator's arguments and a bare `sherlock goose`
defaults to `goose session`.
Verified against the real CLIs (codex 0.153.2, opencode 1.18.27, goose
1.49.0): codex registers both servers with args and env intact, opencode
and goose actually spawn them, and SHERLOCK_LOCAL_CONFIG reaches the MCP
process in every case.
Gemini and Cursor CLIs are deliberately left out: they read MCP servers
only from config files they own, so wrapping them would mean writing
into ~/.gemini, ~/.cursor or the checked-out repository.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: fdf86527-ca08-420d-89ee-47bcee60bebe