[BUG] Claude Code Desktop eager loading MCPs while Claude Code CLI lazy loading
Status Fixed / completed
Maintainer reply None cached
Activity 6 comments · opened Jun 3, 2026 · closed Aug 25, 2026
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?
Eager loading mcp tools at init in Claude Code Desktop app --
<img width="530" height="542" alt="Image" src="https://github.com/user-attachments/assets/3c1a5bca-3387-42fd-a7a4-47daf14d120d" />
What Should Happen?
Lazy loading MCP on claude code CLI
<img width="980" height="650" alt="Image" src="https://github.com/user-attachments/assets/a4f1c039-c04e-4984-858f-6b2b5365379b" />
Error Messages/Logs
Steps to Reproduce
- open claude code cli and type
/context-- observe mcp usage - open claude code desktop and type
/contextobserve mcp usage
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude 1.10628.0 (b4f860) 2026-06-02T05:48:19.000Z
Platform
AWS Bedrock
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Root cause for this (Desktop / Code-tab in 3p mode eager-loads MCP schemas while the standalone CLI defers): the Desktop 3p entrypoint injects
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1into the runtime, and the tool-search mode resolver checks that flag beforeENABLE_TOOL_SEARCH:So on the 3p Desktop surface tool search is forced to
"standard"(off) andENABLE_TOOL_SEARCH=trueis a no-op — whereas the standalone CLI (which does not set the flag) defers correctly through the same gateway, account, model and~/.claude/settings.json. That's exactly the CLI-vs-Desktop split reported here and in the duped #67890.Verified on macOS, runtime
2.1.181:CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1andENABLE_TOOL_SEARCH=true(the user never set the first — the host injects it);--debug,ENABLE_TOOL_SEARCH=true, but withoutDISABLE_EXPERIMENTAL_BETAS, logs[ToolSearch:optimistic] mode=tst, ENABLE_TOOL_SEARCH=true, result=trueand defers (Dynamic tool loading: 0/N deferred tools included).Full write-up, gate-order RE and repro details: anthropics/claude-code#64311 (comment: https://github.com/anthropics/claude-code/issues/64311#issuecomment-4803852141).
The flag is the all-or-nothing experimental-betas kill switch — a defensive default for non-first-party routing — and tool search (
defer_loading/ the tool-search beta) is collateral. A per-beta survive-allowlist (so tool-search stays on whenDISABLE_EXPERIMENTAL_BETAS=1), or simply not forcing the flag on the 3p entrypoint when the gateway forwardstool_referenceblocks, would fix it. The allowlist shape was already requested in #59536.I've encountered the same issue and hope it can be fixed. It would be great if the ToolSearch toggle could be added directly to Claude Desktop's Settings.
Same issue here : having all MCPs eagerly loading makes the desktop app pretty much unusable in terms of context window when running on Bedrock. Seems fine with the Claude API directly, so a fix would be really appreciated!
This makes the desktop app unsuable for me too.
<img width="853" height="483" alt="Image" src="https://github.com/user-attachments/assets/7bed053b-fabf-4e51-a132-196d4c901df7" />