[BUG] Custom connector tools never reach new conversations since Desktop v1.17377.1 (directory connectors fine)

[brunoberger-br]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Heads-up first: this is a Claude Desktop + claude.ai web issue, not a CLI one. I'm filing it here because similar connector reports live in this repo (#73081, #72914 , #72854) and I couldn't find a public tracker for Desktop. Happy to move it if there's a better place.

Since Desktop v1.17377.1 (2026-06-30), my custom connectors (the ones added by URL, with the CUSTOM badge) stopped exposing their tools to conversations. Settings shows them connected, lists all their tools, permissions on "Always allow", no error badge, no Reconnect prompt.

But in any new conversation the tools just never arrive: tool search returns nothing for them (any query), switching Tool access to "Tools already loaded" doesn't help, and asking the model to call a tool by exact name fails because the function isn't in its set. The connector toggle is ON for the conversation. No error anywhere, it just silently doesn't happen.

I tested this across three connectors on the same account. All three use OAuth (all showed the consent screen when re-added), so the only variable left is custom vs directory:

Connector	Type	Result after (re-)adding post-update
A: Open Finance server (mcp.cumbuca.com/mcp, FAPI-strict Keycloak IdP)	CUSTOM	tools never reach any new conversation
B: my self-hosted server (better-auth OAuth)	CUSTOM	same; zero calls ever logged under the new registration
C: Context7	Directory	removed and re-added on purpose as a control: works fine minutes later

A few extra data points that narrow it down:

• Connector B's pre-update registration kept working after the update (successful calls logged 2026-07-02 11:34). It only broke once I deleted and re-added it. So re-registration through the custom path is what kills it.
• Connector A's pre-update registration broke right at the update boundary (last successful calls 2026-06-29 16:25, nothing since). Its IdP issues short-lived tokens, so it was probably the first to hit the new OAuth refresh path.
• An old conversation (created 06-29) could still load and call connector A's tools on 2026-07-02 ~16:09 UTC, under the current post-update registration name. Hours later, in the same conversation, a fresh tool search no longer returns them (it still returns my local desktop-extension MCPs, so search itself is alive). Only the tools already loaded in that session's context remain callable. Looks like cached tool-index state expiring with nothing repopulating it for custom connectors.

Already ruled out: both servers are healthy (proper 401 + WWW-Authenticate challenge), auth works (verified via independent MCP client registrations in Claude Code CLI on the same machine, which still work fine against both servers), full remove/re-add/re-auth multiple times, full app restart, both Tool access modes, per-conversation toggles, and custom skills disabled. Reproduced on claude.ai web too, so it's not the Desktop client alone.

What Should Happen?

A connected connector whose tools are listed in Settings should expose those tools to new conversations. And if its credentials are considered unhealthy, v1.17377.1's own changelog says I should get an authentication error in Settings and a Reconnect action in chat, not a silent no-op. Re-adding a connector should also fully restore it.

Error Messages/Logs

There are no error messages. That silence is part of the bug: Settings shows the
connector healthy, chat shows nothing, and the logs record no failed attempts,
because the tools never reach the model, so no call is ever made.

From %APPDATA%\Claude\logs\claude.ai-web.log (timestamps America/Sao_Paulo):

Last successful calls of connector A's pre-update registration (nothing after these):
2026-06-29 16:25:43 [warn] [MCP] tool_approval_gate {"toolName":"Open Finance (Cumbuca):list_credit_cards",...}
2026-06-29 16:26:31 [warn] [MCP] tool_approval_gate {"toolName":"Open Finance (Cumbuca):get_consent_status",...}

Connector B's pre-update registration still working after the update (before I re-added it):
2026-07-02 11:34:39 [warn] [MCP] tool_approval_gate {"toolName":"Finances:whoami",...}
2026-07-02 11:34:42 [warn] [MCP] tool_approval_gate {"toolName":"Finances:list_cards",...}

Post-update re-registrations: grep of the full log finds ZERO tool_approval_gate
entries under either connector's new registration name, ever. No [MCP] error lines
reference these connectors at all.

Steps to Reproduce

1. On Claude Desktop v1.17377.1+ (or claude.ai web), Settings > Connectors > Add custom connector: add any remote MCP server by URL and complete its OAuth sign-in. (I reproduced with two unrelated servers: a FAPI-strict Keycloak IdP and a plain better-auth OAuth server, both Streamable HTTP.)
2. Confirm Settings shows it connected with all tools listed ("Always allow"). Note there is no error badge and no Reconnect prompt.
3. Start a NEW conversation, toggle the connector ON in the Connectors menu.
4. Ask "List the available tools for ", or ask for a tool by exact name.
5. The model reports the tools are not in its function set; tool search returns none of them. No error appears anywhere.
6. Repeat with the other Tool access mode ("Tools already loaded"): same result.
7. Control: remove and re-add a DIRECTORY connector (I used Context7), same OAuth consent flow. Its tools appear and run normally in a new conversation. So neither OAuth nor re-adding is the trigger; only the custom path is affected.
8. Extra data point: a conversation created before the update could still load and call the custom connector's tools for a while (even the post-update registration), though that access also decayed within hours on 2026-07-02.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop 1.15962.1 (verified working 2026-06-29; version history from local logs). The intermediate 1.15962.2 build landed hours before 1.17377.1 on 06-30 and I can't fully exclude it, but its changelog has no connector changes, while 1.17377.1's changelog is specifically about connector sign-in and reliability handling.

Claude Code Version

2.1.198 (Claude Code). Note: the CLI itself is fine; its own MCP client registrations against the same servers keep working. The bug is on the Desktop/web conversation surface. Currently on Claude Desktop 1.17377.2 (e0ea9e), where the issue persists.

Platform

Other

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

• The timing matches the v1.17377.1 changelog items about connector expired sign-in handling and OAuth refresh reliability. My guess: the new credential health/refresh path silently drops custom connectors from new sessions instead of surfacing the Reconnect error, and whatever cached index served old conversations is expiring with nothing repopulating it.
• In failing conversations the model sometimes reports having no tool_search function at all (only search_mcp_registry and suggest_connectors), and once described the connector as "connected for use in artifacts" but not callable. Registry infra looks fine; the custom connector pipeline is what changed.
• Possibly the same root cause as [BUG] Hosted MCP connectors (Slack/M365) no longer inject into VS Code extension chat after v2.1.195 #73081 (VS Code surface), claude.ai-scoped connectors (Slack/HubSpot/Gmail/Calendar/Drive) show 'Connected' via claude mcp list but are never loaded as tools in a CLI session #72914 and Engineering plugin GitHub connector shows as connected but provides no tools #72854 (CLI surfaces).

[newalive33-sudo]

Confirming this on a newer build — the regression persists on Claude Desktop v1.18286.0.0 (2026-07-04), i.e. still broken several builds after the first-broken 1.17377.1.

Same signature, plus one extra working-surface data point (Cowork):

Surface	Custom remote connector tools
Claude Code CLI	✅ all 16 tools (live-verified today: 7 read + 1 write, all HTTP 200)
Cowork	✅ read + write work
claude.ai chat (web + desktop new conversations)	❌ never injected — silent, exactly as described

Connector: self-hosted streamable-HTTP MCP server (mcp==1.28.1, stateless_http=False, 16 tools, OAuth dynamic client registration). Settings shows "Connected" with all 16 tools "Always allow"; first-party connectors (Slack / Gmail / etc.) inject fine in the same chat surface.

Server is confirmed NOT the cause — full smoke passes from both internal and Anthropic-egress origin:
register 201 -> token 200 -> initialize 200 + Mcp-Session-Id -> tools/list 200 (16 tools) -> GET stream (with sid) 200 text/event-stream -> DELETE 200.
Reproduced with a second, unrelated self-hosted connector too, so it is not server-specific.

main.log corroborates "tools never reach the model":
2026-07-04 16:06 startup (v1.18286.0.0) — only the built-in MCP servers are wired at runtime:

MCP Server connection requested for: mcp-registry
MCP Server connection requested for: claude-in-chrome
[PluginsFetcher] fetchAccountEnabledPlugins: 1 plugins
[PluginsFetcher] fetchBrowsableRemotePlugins: 80 plugins (offset=0, hasMore=false)
[RemotePluginManager] Sync complete: 0 downloaded, 0 removed, 0 orphans cleaned

The custom remote connector never appears as "MCP Server connection requested for", and — consistent with your zero tool_approval_gate finding — nothing further is logged for it. An earlier capture also showed [warn] UtilityProcess Check: Extension <name> not found in installed extensions.

Happy to provide full request/response traces and server config.

[brunoberger-br]

Thanks @newalive33-sudo, still broken for me on 1.18286.0 as well

Your main.log finding matches mine exactly: the client never even attempts the connection (zero tool_approval_gate entries ever for the post-update registrations).

Same surface matrix here too: both of my re-added custom connectors work fine from Claude Code (live-verified today), so the registrations are healthy and it's specifically the chat surface (web + Desktop) that never wires them.