[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

  1. open claude code cli and type /context -- observe mcp usage
  2. open claude code desktop and type /context observe 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_

View original on GitHub ↗

4 Comments

jonathanglasmeyer · 2 months ago

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=1 into the runtime, and the tool-search mode resolver checks that flag before ENABLE_TOOL_SEARCH:

function _Be(){ return rt(process.env.CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS) || D1e("hipaa") }
function dPt(){
  if (_Be()) return "standard";          // tool search OFF — returns before ENABLE_TOOL_SEARCH is read
  let e = process.env.ENABLE_TOOL_SEARCH; ...
}

So on the 3p Desktop surface tool search is forced to "standard" (off) and ENABLE_TOOL_SEARCH=true is 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:

  • the live 3p Desktop runtime process has CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 and ENABLE_TOOL_SEARCH=true (the user never set the first — the host injects it);
  • a headless run of the same runtime binary, --debug, ENABLE_TOOL_SEARCH=true, but without DISABLE_EXPERIMENTAL_BETAS, logs [ToolSearch:optimistic] mode=tst, ENABLE_TOOL_SEARCH=true, result=true and 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 when DISABLE_EXPERIMENTAL_BETAS=1), or simply not forcing the flag on the 3p entrypoint when the gateway forwards tool_reference blocks, would fix it. The allowlist shape was already requested in #59536.

Reflyer823 · 1 month ago

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.

vincentzirah · 1 month ago

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!

ekotler · 1 month ago

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" />

Showing cached comments. Read the full discussion on GitHub ↗