[Bug] /compact and auto-compact fail with 'Tool names must be unique' when MCP servers are configured
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The /compact command and auto-compact fail with "Tool names must be unique" error when MCP servers are configured. This prevents conversation compaction entirely, leaving long sessions unrecoverable.
This appears to be related to #10704 and #10668 (Task tool/subagent failures with same error), but manifests specifically during compaction operations.
Error Messages/Logs
Error during compaction: Error: API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools: Tool names must be unique."},"request_id":"req_..."}
Stack trace from debug logs:
[DEBUG] Getting matching hook commands for PreCompact with query: auto
[DEBUG] Found 0 hook matchers in settings
[DEBUG] Matched 0 unique hooks for query "auto" (0 before deduplication)
[ERROR] Error streaming, falling back to non-streaming mode: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools: Tool names must be unique."}}
[ERROR] Error in non-streaming fallback: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools: Tool names must be unique."}}
[ERROR] Error: Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools: Tool names must be unique."}}
at B9.generate (cli.js:459:10797)
at q_.makeStatusError (cli.js:796:2195)
at q_.makeRequest (cli.js:796:5419)
What Should Happen?
The /compact command should successfully compress the conversation history regardless of MCP server configuration.
Steps to Reproduce
- Configure multiple MCP servers (see configuration below)
- Have an extended conversation that triggers auto-compact or run
/compact - Observe the error: "Error during compaction: Error: API Error: 400 ... tools: Tool names must be unique"
MCP Server Configuration
{
"mcpServers": {
"vercel": {
"type": "http",
"url": "https://mcp.vercel.com"
},
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["@playwright/mcp@latest"]
},
"stripe": {
"type": "http",
"url": "https://mcp.stripe.com/"
},
"shadcn": {
"type": "stdio",
"command": "npx",
"args": ["shadcn@latest", "mcp"]
},
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
}
}
}
Root Cause Analysis
The compaction API call appears to include tool definitions that get duplicated somewhere in the process. This is the same root cause as #10704 (Task tool failures) but affecting the compaction code path.
The error occurs during PreCompact hook processing, suggesting tool definitions are being assembled for the compaction API call and contain duplicates.
Claude Model
claude-opus-4-5-20251101
Is this a regression?
Unknown - first encountered on v2.0.70
Claude Code Version
2.0.70
Platform
Anthropic API
Operating System
macOS 15.6.1 (Darwin 24.6.0)
Terminal/Shell
VS Code integrated terminal
Related Issues
- #10704 - Subagent launch fails with 'Tool names must be unique' when MCP server is configured
- #10668 - Task agent fails with 'tools: Tool names must be unique' when parent has many MCP tools
- #7530 - Error during compaction (general compaction failures)
Workaround
Start a new session. The compaction failure means the current session's context cannot be reduced.
15 Comments
Confirming this issue with additional MCP server configuration
I can confirm this exact same issue on v2.0.70 with a different set of MCP servers.
My Error
My MCP Server Configuration
I have 12 active MCP servers configured (more than the original report):
Observations
/compactand auto-compact fail with the identical errorImpact
This makes long sessions completely unrecoverable once token budget gets high enough to require compaction. The only option is
/clearand losing all context.Additional Context
Model:
claude-sonnet-4-5-20250929Platform: macOS 15.0.0 (Darwin 25.0.0)
Session context: Working in a large codebase with multiple active specs
This appears to scale with the number of MCP servers - I have more servers configured than the original report, which may increase the likelihood of tool name collisions during compaction.
Try to disable all your MCPs; then exit claude code. Then start again --continue and run /compact
worked for me
It works. So weird – my MCP setup used to work fine, but now I have to disable all MCP servers just to use /compact, lol.
FYI, I did absolutely nothing and it resolved on its own a few hours ago.
I'm having the same issue
For me it happens especially on VScode. i found a workaround. exit VScode. open your session in a terminal and run /compact and continue for at least one run. then you can go back to vscode again.
same here
Additional reproduction on Linux
Experiencing the same issue on Linux (Ubuntu, kernel 6.11.0-29-generic).
Environment:
MCP servers configured:
Error (identical to OP):
Screenshot attached showing context usage and error:
The error occurs both on manual
/compactand when auto-compact triggers at >100% context usage.This confirms the issue affects all platforms (macOS, Windows per other issues, and now Linux).
this is a bug in
2.0.70, downgrade to2.0.69helps, addDISABLE_AUTOUPDATER=1to your env beforeI am having the exact same problem. First time ever starting today. Tested it in terminals in Cursor and Warp and MacOS - same issue. Tried to disable MCPs and restart - didn’t work.
Thanks all for reporting - yes, this was a new (2.0.70) regression. Should be fixed in the next version. Meanwhile @spada23 's workaround should be effective for most cases:
Hey team, same bug here:
> /compact⎿ Error: Error during compaction: Error: API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools: Tool names must be unique."},"request_id":"req_011CWB67UjnnTva4HTiqzRKS"}
Environment Info
Platform: Windows
Terminal: Powershell
Version: 2.0.70
Manage MCP servers _(2 servers)_
Just came to confirm that version 2.0.71 successfully auto-compacts with all of my MCP servers enabled! Great work on the rapid fix/release!
@erraggy thanks for confirming!
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.