[BUG] Claude MCP entry keeps the old url/headers when a server's transport changes from http to stdio

[ahegyes]

Describe the bug

When a self-defined MCP server that apm previously wrote to ~/.claude.json as an HTTP server (url, headers) is declared again under the same name as a stdio server (command, args, env), the install merges the new definition into the existing entry instead of replacing it. The resulting entry describes both transports at once.

Where, in the 0.30.0 source

• adapters/client/claude.py, _merge_mcp_server_dicts: each server entry is shallow-merged, {**old, **new}, so every key only the old entry had survives. The docstring gives the reason (keep hand-authored keys such as OAuth blocks), but transport-specific keys survive with them.
• adapters/client/claude.py, _normalize_mcp_entry_for_claude_code: an entry that still has a url is classified as remote and returned as is, so the stdio normalisation never applies to the merged entry.
• Observed on a user-scope install after such a change: mcpServers.<name> held the keys type (local), url and headers from the old HTTP definition, and command, args and env from the new stdio one.

To Reproduce

The resulting entry was observed; these steps are derived from the source and were not run as a standalone script.

1. Install, with -g -t claude, a package whose apm.yml declares {name: example, registry: false, transport: http, url: "http://127.0.0.1:4521/mcp", headers: {Authorization: "Bearer ${TOKEN}"}}.
2. Replace that declaration with {name: example, registry: false, transport: stdio, command: npx, args: ["-y", "example-mcp"]} and install again.
3. ~/.claude.json → mcpServers.example carries url and headers alongside command and args.

Expected behavior

When a server's declared transport changes, the keys specific to the previous transport (url, headers for a remote server; command, args, env, cwd for stdio) are dropped, so the entry describes exactly one transport. Keys apm never manages can still be preserved.

Environment

• OS: macOS, Apple Silicon
• APM: Homebrew binary, Agent Package Manager (APM) CLI version 0.30.0
• Scope: user (-g), target claude

[sergio-sisternes-epam]

Thanks for the source-backed report. The user-visible failure is real:
apm install -g -t claude is supposed to reproduce the declared MCP
server, but a shallow {**old, **new} merge in the Claude adapter
leaves remote url/headers after the same name is redeclared as
stdio. Because normalize still treats a leftover url as remote, the
stdio shape never wins, and stale Authorization headers can remain in
~/.claude.json.

This looks like a bounded adapter bug, not a new product surface. The
direction that fits APM's install promise is: on transport change, drop
previous-transport keys and keep only unmanaged keys. That still needs
a human maintainer to approve scope before anyone implements it.

Concrete next step: wait for that human scope record on this issue.
Please do not open a PR until a maintainer records approval.

---

Generated by autopilot-issue-triage-worker. This comment is AI-generated and may contain errors.

[edenfunf]

Picking this up from the status/accepted queue -- no linked PR and nobody else has claimed it.

Reproduced on main (98616b9) through a real apm install -g -t claude: after the http -> stdio redeclaration the entry keeps url and headers, and because the leftover url re-classifies it as remote, _normalize_mcp_entry_for_claude_code never runs the stdio branch, so type stays at Copilot's local instead of stdio. The reverse direction leaks command/args the same way.

Fix keeps to the advisory direction: drop the replaced transport's keys before the shallow merge, leave unmanaged keys (hand-authored OAuth blocks) untouched. PR on the way.