[BUG] "Tool Access" / "On Demand" setting in Claude.ai and Claude Desktop does not persist or defer tools

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?

Note: This bug affects the consumer apps (claude.ai and Claude Desktop), not Claude Code CLI. I'm filing it here because it's technically related to the tool search infrastructure documented in #19890, #18397, #18298, and #19560, and there is no public issue tracker for the consumer apps.

Summary

The "Tool Access" setting (accessible via "+" → "Connectors" → "Tool access") has two bugs:

1. UI persistence bug: The setting cannot be changed before the first message in a new conversation. Selecting "On Demand" closes the menu but silently reverts to "Auto."

1. Functional bug: Even when "On Demand" is successfully activated (via a mid-conversation workaround), all MCP tools remain fully loaded with complete JSON schemas. The tool_search mechanism appears in addition to the full tool definitions rather than replacing them, consuming more context than "Auto."

What Should Happen?

1. The "Tool Access" setting should persist when changed before the first message.
2. When "On Demand" is selected, MCP tools should be deferred, with only tool_search loaded. Tools should be loaded on-demand when relevant to the task.

Error Messages/Logs

Steps to Reproduce

Environment

• Claude Max subscription
• Tested on both claude.ai (web app) and Claude Desktop (Windows)
• Windows 11
• MCP servers: Todoist, Claude in Chrome, Desktop Commander, Windows-MCP (~110 tools in Desktop, ~57 in web app)
• Date tested: February 15, 2026

Bug 1: Setting reverts before first message

1. Open a new conversation (no messages sent yet).
2. Click "+" → "Connectors" → "Tool access."
3. Select "On Demand."
4. The menu closes.
5. Reopen the same menu: "+" → "Connectors" → "Tool access."
6. Result: Setting has reverted to "Auto."

Reproducible 100% of the time in both web app and desktop app.

Workaround: Send any message first, then change the setting. It persists mid-conversation.

Bug 2: Tools not deferred despite "On Demand"

1. Start a new conversation and send a message.
2. Change "Tool access" to "On Demand" (setting now persists).
3. Ask Claude to list all available tools.
4. Expected: Only a tool_search meta-tool is loaded. MCP tools are deferred.
5. Actual: All MCP tools are fully loaded with complete JSON schemas AND tool_search is present as an additional mechanism. Tools appear in both the full schema and the deferred index.

Calling tool_search confirms it only returns tools that are already fully loaded. No tools are actually deferred.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A (Consumer apps: claude.ai and Claude Desktop)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Relation to existing Claude Code issues

This is the consumer-app equivalent of the auto-detection failures reported in:

• #19890 (auto mode not triggering at 24.8% context usage)
• #18397 (auto mode not triggering at 35.3% context usage)

The Claude Code workaround (ENABLE_TOOL_SEARCH=true) has no equivalent in the consumer apps. The claude_desktop_config.json env block passes variables to MCP server processes, not to the client's tool-loading logic.

Impact

With ~110 MCP tools consuming an estimated 22,000 to 44,000 tokens in schema definitions before any user input, the "Tool Access" feature is critical for power users with multiple MCP integrations. The help center article "Use the Connectors Directory to extend Claude's capabilities" recommends "On Demand" for 10+ connectors, but the feature does not function as described.

Additional context

• The setting was also tested inside Claude Projects. Same behavior.
• Global settings (Ctrl+Comma) contain no "Tool Access" option.
• The API-level defer_loading: true beta works correctly. The consumer apps do not appear to use this mechanism.