[BUG] Custom connector tools never reach new conversations since Desktop v1.17377.1 (directory connectors fine)
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?
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
- 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.)
- Confirm Settings shows it connected with all tools listed ("Always allow"). Note there is no error badge and no Reconnect prompt.
- Start a NEW conversation, toggle the connector ON in the Connectors menu.
- Ask "List the available tools for <connector>", or ask for a tool by exact name.
- The model reports the tools are not in its function set; tool search returns none of them. No error appears anywhere.
- Repeat with the other Tool access mode ("Tools already loaded"): same result.
- 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.
- 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_searchfunction at all (onlysearch_mcp_registryandsuggest_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 #73081 (VS Code surface), #72914 and #72854 (CLI surfaces).
8 Comments
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:
The custom remote connector never appears as "MCP Server connection requested for", and — consistent with your zero
tool_approval_gatefinding — 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.
Thanks @newalive33-sudo, still broken for me on 1.18286.0 as well
Your
main.logfinding matches mine exactly: the client never even attempts the connection (zerotool_approval_gateentries 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.
Update: still broken on Desktop 1.19367.0 - fresh conversation, connector toggled on, zero tools injected:
<img width="898" height="941" alt="Image" src="https://github.com/user-attachments/assets/dc81076f-3878-4cc0-9b55-3419276a00f7" />
<img width="893" height="876" alt="Image" src="https://github.com/user-attachments/assets/ffd835d4-0584-4bea-9316-1283f9270d29" />
Fourth consecutive broken build since 1.17377.1.
Confirming this on Max plan, macOS, both claude.ai web and Claude Desktop. Same regression boundary: last working 6/30/2026 (v1.17377.1 release date), broken 7/6, still failing 7/7 in fresh chats. Flagging because the current platform:windows label is too narrow. This reproduces on Mac, so the fault is not OS-specific.
Data point that may widen scope beyond the issue title. My failing connector is monday.com, a directory-listed hosted connector, not a custom URL connector. The "directory connectors fine" framing does not hold here. If a directory connector is affected, a fix scoped only to the custom-registration path may not resolve it.
Same silent signature you documented: connector shows connected, all tool groups on Always allow (Interactive 4, Read-only 29, Write/delete 43), fresh OAuth with write scopes approved, no error badge, no Reconnect prompt, tools never register in new conversations. Disconnect/reconnect, re-auth, and fresh OAuth do not resolve. Brief self-recovery on 7/6 followed by re-failure, matching the cached tool-index decay you described.
Confirming your specific fingerprint: in the failing session the model reports no tool_search function, only search_mcp_registry and suggest_connectors, and none of the connector's tools are in its set. Isolation on my side: in a single fresh session, eight other connectors registered tools normally (Canva, Gmail, Google Calendar, Lucid, Microsoft 365, Plaud, Supabase, n8n). Only monday.com registered zero. So it is not client-wide and not auth.
Update: Found the failure point. Two probes, highlights below (full debug report available).
Probe 1: fetch interception on the completion endpoint (claude.ai web, fresh conversation)
Probe 2: artifacts route (
mcp_serversin /v1/messages)server_namecomes back rewritten to the registration UUID; the directory connector's does not. Custom registrations take a distinct backend path, and it works everywhere except chat.Re @H0ss68's monday.com case: my directory controls (Context7, Windsor.ai) still pass today, so the mechanism is probably a per-registration backend lookup failing silently and treated as "exclude", with custom registrations as the dominant casualty, rather than a strict custom-vs-directory split.
Workarounds (all verified working):
| Surface | Workaround |
|---|---|
| Desktop |
mcp-remotestdio bridge inclaude_desktop_config.json(restored both connectors, FAPI IdP included; caveat: reused cached~/.mcp-authtokens, from-scratch DCR not exercised) || claude.ai chat | artifact passing the connector via
mcp_servers, OAuth + tool calls work end-to-end || Claude Code CLI | unaffected, keeps working |
So every path EXCEPT chat-context assembly handles these registrations fine.
For engineers: affected registration UUIDs
a18583b2-26ca-41f2-bbca-e6327987941eanda0854f3f-0ce0-49e6-bb41-09e40cc001b6(org ID on request).Adding an inverse-surface data point on Windows 11 Home 25H2 (Build 26200.8655), Claude Desktop 1.20186.0.
For me the broken surface is the opposite of the title: directory connectors (Microsoft 365, Google Drive, Shopify, Xero, Klaviyo, Slack, Semrush, Metricool, Canva) all work correctly in normal chat, but their tools never load in any Cowork session. They all appear in the + menu inside Cowork with no error badge, they just never reach the model.
Broke immediately after a forced re-login/update yesterday morning (9 July 2026). Persists after: connector toggle off/on, full quit and restart, switching tool access mode Auto to On demand, and a complete uninstall and clean reinstall with sign-out/sign-in.
Same silent signature everyone's describing: Settings shows connected, all tools listed on Always allow, no Reconnect prompt, tools simply never arrive in the session.
One extra data point: my %LOCALAPPDATA%\Claude\logs folder contains only chrome-native-host — there is no main.log and no MCP/connector logs at all. The %APPDATA%\Roaming\Claude path doesn't exist. Suggests the connector/MCP subsystem isn't initialising or logging for Cowork on this install.
So this reproduces on first-party directory connectors (not just custom URL connectors) and on the Cowork surface specifically, which widens the scope beyond both the "custom-only" and "chat-only" framings above.
Following up on my earlier comment, because this has now seriously disrupted a business that runs on Claude, and I want the impact on the record.
Since the 9 July regression, my Cowork sessions are effectively unusable. The sessions still open, but they cannot connect to their linked Google Drive folders or any connectors, so I can't actually work in them. Every Cowork session I open throws "The requested project was not found," and the connector tools never load. My working files are still in Drive, but the sessions can't reach them, which makes the entire Cowork workflow dead in the water.
To be clear about scope: this is not a minor connector inconvenience. I run a business through Claude on a Max plan, with a full connector stack (Microsoft 365, Google Drive, Shopify, Xero, Klaviyo, Slack, Semrush, Metricool, Canva) and substantial complex work built up in Cowork over months. All of that is currently inaccessible for actual use.
I have raised this through official support five separate times and have never received a response from a human on any of them. The only substantive help I've had has come from this GitHub thread. For a paying Max subscriber losing core functionality, that's not an acceptable support experience, and I'd ask that this be escalated accordingly.
Environment: Windows 11 Home 25H2 (Build 26200.8655), Claude Desktop 1.20186.0. Same silent signature as the rest of this thread — connectors show connected, tools listed, no error badge, tools never reach the session. Persists after clean uninstall/reinstall and re-login.
Getting this one too, on Cowork (macOS, Desktop 1.19367.0).
The connector in my case is Coworker (odin.coworker.ai/mcp) — added by URL, OAuth, shows the CUSTOM badge. It's connected as far as everything can tell: connected: true when I list connectors in-session, all tools listed, permissions granted, no error badge, no Reconnect prompt. But the tools just never show up in the session. Tool search comes back empty for it no matter what I search — the name, the domain, the actual capability (it's a Salesforce/CRM connector and none of salesforce/soql/records surface anything). If I try to call a tool by name it fails because it's not in the set.
What makes me think it's this issue and not #76604: every other connector in the same session works fine — Gmail, Slack, Drive, Calendar, plus a couple of other URL-added servers. So it's not custom connectors failing across the board, it's just this one going silent, which sounds like exactly what you're describing rather than the directory-connector inverse.
Already tried the usual — toggling it off/on, re-running tool discovery a bunch of times. Nothing errors out, the tools just aren't there.
Connector directory UUID is 8a15c530-d4ac-496b-98cb-59a11a86d7d1 if that's useful. Can grab the per-account registration UUID from the logs and run whatever diagnostics help.