Connected HTTP MCP server's tools never appear in tool registry (ToolSearch) even after full app restart

Description

After adding an HTTP-transport MCP server and completing OAuth, claude mcp get <name> reports ✓ Connected, and the server's tools/list (verified by calling the MCP endpoint directly with the stored OAuth token via curl) returns a full, valid tool catalog. However, the tools never become discoverable through the in-session tool registry (the deferred-tools search mechanism used internally) — not at session start, not after reconnecting the server, and not after a full quit-and-reopen of the application (not just "Reload Window").

Steps to reproduce

1. claude mcp add --transport http <name> <url>
2. Complete the OAuth browser flow (server requires auth) — credentials get persisted to ~/.claude/.credentials.json under mcpOAuth, keyed by <name>|<hash> with a valid accessToken/refreshToken.
3. claude mcp get <name> → Status: ✓ Connected.
4. Independently verify the server works: POST initialize then tools/list directly to the server URL with Authorization: Bearer <accessToken> and the returned Mcp-Session-Id header → full tool list returned (confirmed working, e.g. images_generate, video_generate, etc. on a real third-party server).
5. Search for any of those tool names in-session → no matching tools found.
6. Fully quit and relaunch the application (confirmed: not just a window/extension reload, an actual process restart) → tools still do not appear for that server, despite claude mcp get still showing Connected.

Expected behavior

Once claude mcp get <name> shows Connected, that server's tools should be discoverable in-session (or at minimum, after a full application restart).

Actual behavior

Tools remain permanently undiscoverable in-session even though the underlying MCP connection and OAuth are fully functional, verified independently outside the app via direct HTTP calls to the same server/token.

Environment

• Claude Code version: 2.1.153
• Platform: Linux (Ubuntu 24.04), running as a VS Code extension session over RDP
• MCP transport: http, OAuth-protected (Keycloak-backed authorization server, separate from the resource server)
• Two credential entries were observed in .credentials.json for the same server name with slightly different serverUrl values (with/without trailing slash) from earlier reconfiguration attempts — final working config matches the URL with the complete token, and claude mcp get correctly reports Connected for it, but this did not resolve the tool-discovery gap.

Notes

This was reproduced over a long debugging session: confirmed not a DNS/network/auth/URL-path issue (all fixed in turn, with claude mcp get eventually showing Connected), not a stale-credential issue (token verified valid and complete via direct curl test), and not a "didn't actually restart" issue (user confirmed a full quit-and-reopen, not just reload window).