Summary
When auggie --acp is driven by a host that supplies a non-empty mcpServers array in the session/new (or session/load/fork) request, Auggie completely replaces the MCP servers configured in ~/.augment/settings.json / project .mcp.json with only the servers the host sent, instead of merging the two lists. Any MCP server the user has configured locally (and that the host doesn't know about) silently disappears for the ACP session, with no warning to the user.
Environment
auggie installed via npm (@augmentcode/auggie), latest version at time of writing
- Host: a custom ACP client/editor integration that spawns
auggie --acp and always sends at least one MCP server (its own workspace-context server) in session/new
- OS: macOS
Steps to reproduce
- Configure an MCP server in
~/.augment/settings.json (or a project .mcp.json), e.g. a Playwright-Electron server named playwright-electron.
- Run
auggie interactively and check /mcp — the server is listed and available, confirming the config itself is valid.
- Run
auggie --acp under a host that sends a non-empty mcpServers array in session/new (e.g. a single workspace-context server).
- Inspect the tools available in the resulting session, or the child processes of the
auggie --acp process.
Expected behavior
The MCP servers the host supplies via session/new.mcpServers are added to the servers defined in the user's ~/.augment/settings.json / .mcp.json, the same way auggie's own CLI merges --mcp-config with settings-defined servers. A user-configured server should still be available in an ACP session unless it conflicts (e.g. same name) with a host-supplied one.
Actual behavior
- The
auggie --acp process never spawns the locally-configured MCP server (confirmed via process tree: no child process for the server's launch command exists under the auggie --acp PID, only the host-supplied server(s)).
- Only the tools from the host-supplied
mcpServers array are exposed to the session.
Root cause (from reading the installed augment.mjs bundle)
Two functions are involved:
-
createSession(e, n, r, i) — the ACP session/new handler. e.mcpServers is what the host sent. If it is non-empty, it is turned into tools.mcpConfig for the session config; only when the host sends an empty array does it fall back to this.rootConfig.tools.mcpConfig (the config resolved from the CLI's own --mcp-config/settings at process startup):
async createSession(e,n,r,i){
let o=e.mcpServers||[];
...
tools:{...this.rootConfig.tools,
mcpConfig: s.length>0 ? s.map(l=>JSON.stringify(l)) : this.rootConfig.tools.mcpConfig}
-
v3e(t, e, n, r, i, o) — builds the final list of MCP servers for the session. t is settings.json's mcpServers; e is the mcpConfig computed above (i.e. whatever the host sent, once non-empty). When e is non-empty, t (settings.json) is ignored entirely — there is no merge step:
function v3e(t,e,n,r,i,o){
...
if(!e || e.length===0){
// e empty -> read from settings.json (t)
...
}
// e non-empty -> t is never consulted; only e is used
c = await Uzn(e);
...
}
It is called at session-creation time as:
let{mcpServers:xe,warns:Ce} = await v3e(i.mcpServers, this.config.tools.mcpConfig, ...)
i.mcpServers is the settings.json value; this.config.tools.mcpConfig is exactly the array createSession just populated from the host's session/new.mcpServers. Because it's an "or" (host servers replace settings) rather than a merge, any host that sends even one MCP server (which is the common case for an ACP host that provides its own workspace-context tools) causes every user-configured server to be dropped for that session.
Suggested fix
Merge the two lists in v3e (keyed by server name, host-supplied entries winning on conflict) instead of treating a non-empty host list as fully authoritative. This would match the behavior of Claude Code and Codex CLI, which both continue to load a project's .mcp.json in ACP mode in addition to whatever the host supplies via session/new.
Happy to provide more logs/evidence if useful.
Summary
When
auggie --acpis driven by a host that supplies a non-emptymcpServersarray in thesession/new(orsession/load/fork) request, Auggie completely replaces the MCP servers configured in~/.augment/settings.json/ project.mcp.jsonwith only the servers the host sent, instead of merging the two lists. Any MCP server the user has configured locally (and that the host doesn't know about) silently disappears for the ACP session, with no warning to the user.Environment
auggieinstalled via npm (@augmentcode/auggie), latest version at time of writingauggie --acpand always sends at least one MCP server (its own workspace-context server) insession/newSteps to reproduce
~/.augment/settings.json(or a project.mcp.json), e.g. a Playwright-Electron server namedplaywright-electron.auggieinteractively and check/mcp— the server is listed and available, confirming the config itself is valid.auggie --acpunder a host that sends a non-emptymcpServersarray insession/new(e.g. a single workspace-context server).auggie --acpprocess.Expected behavior
The MCP servers the host supplies via
session/new.mcpServersare added to the servers defined in the user's~/.augment/settings.json/.mcp.json, the same wayauggie's own CLI merges--mcp-configwith settings-defined servers. A user-configured server should still be available in an ACP session unless it conflicts (e.g. same name) with a host-supplied one.Actual behavior
auggie --acpprocess never spawns the locally-configured MCP server (confirmed via process tree: no child process for the server's launch command exists under theauggie --acpPID, only the host-supplied server(s)).mcpServersarray are exposed to the session.Root cause (from reading the installed
augment.mjsbundle)Two functions are involved:
createSession(e, n, r, i)— the ACPsession/newhandler.e.mcpServersis what the host sent. If it is non-empty, it is turned intotools.mcpConfigfor the session config; only when the host sends an empty array does it fall back tothis.rootConfig.tools.mcpConfig(the config resolved from the CLI's own--mcp-config/settings at process startup):v3e(t, e, n, r, i, o)— builds the final list of MCP servers for the session.tissettings.json'smcpServers;eis themcpConfigcomputed above (i.e. whatever the host sent, once non-empty). Wheneis non-empty,t(settings.json) is ignored entirely — there is no merge step:It is called at session-creation time as:
i.mcpServersis the settings.json value;this.config.tools.mcpConfigis exactly the arraycreateSessionjust populated from the host'ssession/new.mcpServers. Because it's an "or" (host servers replace settings) rather than a merge, any host that sends even one MCP server (which is the common case for an ACP host that provides its own workspace-context tools) causes every user-configured server to be dropped for that session.Suggested fix
Merge the two lists in
v3e(keyed by server name, host-supplied entries winning on conflict) instead of treating a non-empty host list as fully authoritative. This would match the behavior of Claude Code and Codex CLI, which both continue to load a project's.mcp.jsonin ACP mode in addition to whatever the host supplies viasession/new.Happy to provide more logs/evidence if useful.