fix: one name for the memory MCP server; drop "Claude" from a shared notice - #307
Merged
Merged
Conversation
…notice Both surfaced in a live qwen session and both are backend-leakage bugs. 1. The memory MCP server had two names. `MEMORY_MCP_SERVER_NAME` is "codeoid_memory" and every mount key and `isSafeTool` prefix derives from it, but `buildMemoryMcpServer` hard-coded the INSTANCE name as "codeoid-memory". Backends disagree about which of the two they namespace mounted tools by: the Claude SDK uses the mcpServers map KEY, qwen-code uses the instance's own name. So on the qwen backend the recall tools were exposed as `mcp__codeoid-memory__*`, which matched neither the provider's `allowedTools` grant nor any `isSafeTool` prefix — and the read-only memory tools raised an approval prompt on every single call, when the whole point is that recall is transparently available. Claude was unaffected, which is why nothing caught it. The instance now uses the constant. One name removes the class of mismatch rather than teaching each backend about both spellings. The test that asserted the literal is the reason this survived, so it now asserts against the constant and additionally checks the resulting tool names are auto-approvable. 2. A shared code path named Claude. The mid-turn queue notice is reached by any keep-warm backend that supports injection, but read "Claude is re-integrating with new context". In a Qwen session that renders between the user's question and Qwen's answer, which reads like the wrong backend replied — the observation that started this investigation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rsharath
approved these changes
Aug 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two backend-leakage bugs, both found in a live qwen session.
1. The memory MCP server had two names
MEMORY_MCP_SERVER_NAMEcodeoid_memoryisSafeToolprefixesmcp.ts)codeoid-memoryBackends disagree about which one they namespace mounted tools by: the Claude SDK uses the
mcpServersmap key; qwen-code uses the server instance's own name.So on qwen the recall tools were exposed as
mcp__codeoid-memory__*— matching neither the provider'sallowedToolsgrant nor anyisSafeToolprefix. The read-only memory tools raised an approval prompt on every call, when the entire point of recall is that it's transparently available.Claude was unaffected (map key = the constant), which is exactly why nothing caught it.
Visible in a real transcript — same session, adjacent turns:
Fix: the instance uses the constant. One name removes the whole class of mismatch, rather than teaching each backend about both spellings.
The test is the reason this survived — it asserted the literal
"codeoid-memory", so it passed while the divergence existed. It now asserts against the constant and additionally checks the resulting tool names are actually auto-approvable, which is the property that was broken.2. A shared code path named Claude
The mid-turn queue notice is reached by any keep-warm backend supporting injection, but read:
In a Qwen session that renders between the user's question and Qwen's answer, reading like the wrong backend replied. This was the observation that kicked off the investigation.
Not included
While confirming this I also saw the qwen
mcp_inittool count vary across turns with an identical server list (64 → 153 → 125). That's a discovery race — a snapshot taken before MCP discovery settles, not a leak, since counts fall as well as rise. It needs a separate look and isn't bundled here.Verification
lint+typecheckclean, 2383 pass / 0 fail.🤖 Generated with Claude Code