[BUG] Native Anthropic tool tier silently disappears from advertised functions list on Claude for Windows 1.3883.0

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?

On Claude Desktop for Windows 1.3883.0, native Anthropic tools silently drop out of the model's advertised function list as a conversation grows. The most likely trigger is conversation compaction. MCP connector tools (Filesystem, Chrome, PDF Tools, Indeed) persist through the same compaction and are not affected.

The tools that disappear include:

• bash_tool
• python / code execution
• view, create_file, str_replace
• tool_search
• web_search, web_fetch
• conversation_search, memory_user_edits
• image_search

Because tool_search itself is a native tool, when it drops the session loses the ability to deferred-load replacements. The session effectively cannot recover on its own.

The failure mode is worse than a total outage because the model often doesn't realize a tool is missing until it tries to call it, at which point context is already spent on wrong guesses or workarounds.

Note: this form is labeled "Claude Code" but the bug is in the Claude Desktop consumer app. Filing here based on precedent of other Desktop bugs accepted in this repo (#28231, #38783). Several fields below may not map cleanly to a Desktop bug.

What Should Happen?

Native Anthropic tools should stay available for the full conversation, consistent with how MCP connector tools behave. At minimum, the model should either be informed when a tool drops so it can notify the user instead of calling and failing, or should be able to refresh its tool manifest without needing the user to paste a settings screenshot.

Error Messages/Logs

No formal error message. The failure mode is silent. Observed behaviors:

- Native tool calls made by the model fail at the transport layer with no structured tool error.
- MCP connector tool calls on Filesystem occasionally time out with: "No result received from the Claude Desktop app after waiting 4 minutes. The local MCP server providing this tool may be unresponsive, crashed, or not running." This happens in the same sessions where native tools have dropped, suggesting manifest or transport state is broader than a single tool.
- The model's own callable-functions list no longer contains the native tools after compaction. The model can confirm this when asked directly.

Steps to Reproduce

1. Open a new conversation on Claude Desktop for Windows 1.3883.0 with Opus 4.7 selected.
2. Pre-check: Settings -> Capabilities -> "Cloud code execution and file creation" is ON; "Allow network egress" is ON with All domains; "Tool access mode" is "Load tools when needed".
3. Early in the session, have Claude use a native tool (for example, run bash echo alive or write a small file). Confirm the tool works.
4. Continue the conversation long enough to cross at least one compaction boundary (typically 30+ turns, fewer if turns are long).
5. After compaction, ask Claude to use any native tool again.
6. Observed: the tool is either not listed in Claude's callable functions, or errors immediately when called. Meanwhile MCP connector tools (Filesystem, Chrome, PDF) still work.

Partial workaround for verification: pasting a screenshot of the Settings -> Capabilities panel into the conversation appears to force a tool manifest refresh. The native tools come back for a few turns, then drift out again. Repeatable across sessions.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Not applicable - this is a Claude Desktop bug, not Claude Code. Claude Desktop for Windows version: 1.3883.0 (93ff6c)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Configuration (verified repeatedly during debugging):

• Settings -> Capabilities -> "Cloud code execution and file creation": ON (has been ON since install, never toggled off)
• Settings -> Capabilities -> "Allow network egress": ON, All domains
• Tool access mode: "Load tools when needed"
• No overrides at the organization level

Workarounds that did NOT fix it:

• In-app quit and restart
• Multiple consecutive full app restarts
• Starting a fresh conversation within the same app session
• Toggling Tool access mode between "Load tools when needed" and "Tools already loaded"

Possibly related existing issues:

• #38783 (Windows Cowork browser automation tools missing after Desktop update). Different symptom, but the shape matches. Tools are referenced in the allowed list but never actually register.
• #45896 (Windows Desktop updater leaves stale file lock requiring full OS reboot). Possibly related to why in-app restarts don't clear the broken state.
• #28180 (Windows Claude Desktop MCP connection errors after app crash). Similar transport-state corruption after a state event.

Happy to provide additional logs, app state data, or reproduction traces on request.

<img width="1027" height="392" alt="Image" src="https://github.com/user-attachments/assets/d317847c-5ba4-40e8-92c2-9d82538aaea9" />
<img width="321" height="415" alt="Image" src="https://github.com/user-attachments/assets/42d818f6-f413-4ec8-9e85-a84cb7e9a009" />