Custom connector: overnight OAuth refresh/DCR succeeds, but existing chat never calls /mcp until new conversation + reconnect (“stale session”)

### What happened?

After a successful day of using a custom remote MCP connector in claude.ai, returning the **next day** in an **existing conversation** shows this pattern on our server (audit_log):

- A successful refresh_token exchange on /oauth/token.
- Then a successful DCR/OAuth path (/register → authorize → callback).
- Despite that, tool use in the **same existing conversation** fails with a **stale session** style failure.
- Critically: **no tool-call traffic reaches** /mcp during the failure. OAuth succeeds; MCP tool POSTs do not appear.

Recovery that works:

- Disconnect / reconnect the custom connector (Settings → Connectors).
- Open a **new** conversation.
- Query the MCP server again.

In the working path, the **first** audited call is to /mcp, then OAuth/register/callback as needed, and tools succeed.

So overnight token refresh alone is not enough to restore tools in an already-open chat; a new conversation + connector rebind is required.

This is **not**:
- A missing OAuth refresh (unlike [#228](https://github.com/anthropics/claude-ai-mcp/issues/228) — we *do* see a successful `refresh_token`).
- A connect-time “zero requests / server configuration issue” (unlike [#479](https://github.com/anthropics/claude-ai-mcp/issues/479) — Anthropic traffic reaches our server for OAuth/DCR).
- A revoked-token `/mcp` 401 mislabeled as “server isn’t responding” (unlike [#744](https://github.com/anthropics/claude-ai-mcp/issues/744) — in our broken path, tool calls do not reach `/mcp` at all).

It *is* in the same family as overnight/idle connector recovery issues:
- Closest cousin: [#795](https://github.com/anthropics/claude-ai-mcp/issues/795) (after idle, tools unusable until reconnect), **except** [#795](https://github.com/anthropics/claude-ai-mcp/issues/795) describes a dead refresh token with no successful refresh; we still complete `refresh_token` (+ DCR/OAuth) and then the **existing** chat never rebinds `/mcp`.
- Also related: [#469](https://github.com/anthropics/claude-ai-mcp/issues/469) Defect 3 (conversation permanently loses tools; new chat / toggle connector recovers) and [#450](https://github.com/anthropics/claude-ai-mcp/issues/450) (session re-init).

### What did you expect to happen?

After a successful overnight token refresh (and any needed re-auth/DCR):

- The connector should re-bind / re-initialize the MCP transport for the existing conversation (or transparently recover).
- Subsequent tool calls should reach POST /mcp with a valid bearer token.
- Users should not need a new chat + manual disconnect/reconnect for normal next-day use.

Per MCP Streamable HTTP session management, when a session is no longer valid the client should start a new session via a fresh InitializeRequest without a stale session id — not leave the conversation unable to issue /mcp calls after OAuth has already succeeded.

### Steps to reproduce

- Add a custom remote Streamable HTTP + OAuth/DCR MCP as a custom connector.
- Connect and authorize successfully.
- In a conversation, enable the connector and successfully call MCP tools (confirm /mcp + TOOL_EXEC in server audit logs).
- Leave overnight (access token expires; optionally also restart the MCP process — see Additional context).
- Next day, open the **same existing conversation** and ask a question that requires MCP tools.
- Observe:
- - Server audit: `refresh_token` success, then register/auth/callback success.
- - No (or no useful) /mcp tool traffic for the attempted tool use.
- - UI reports stale session / tool failure.
- Disconnect + reconnect the connector, open a **new** chat, repeat the query.
- Observe: first audited call is /mcp, then tools succeed.

### Area

Session / Connection Management

### MCP Server (if applicable)

Custom remote MCP

### Error messages or logs

```shell
# Broken path (existing conversation, next day) — server audit_log order
1) POST /oauth/token grant_type=refresh_token success=true
2) POST /register (DCR) success
3) OAuth authorize + callback success
4) (missing) POST /mcp tools/call — does not appear / tools never reach server

# Working path (disconnect/reconnect + NEW conversation)
1) POST /mcp (initialize / tools path) appears first
2) register/auth/callback as needed
3) subsequent POST /mcp tool calls succeed

# UI
Claude ai web says,
I don't have the Custom MCP tools available in this conversation, so I can't run whoami here. The tool surface I have loaded is Anthropic's built-in set (search, file, visualization, etc.) - none of the custom-mcp tools.

# Timestamps (UTC) from server audit_log
Broken attempt window: 2026-08-11 17:42:55.522237 to 2026-08-11 17:43:17.472
Working attempt window: 2026-08-11 18:03:43.039818 to 2026-08-11 18:03:51.699423
```

### Additional context

Client

- Product: claude.ai `web` . We currently use DCR (Advanced credentials blank)
- Browser version : `Edge, 151.0.4129.72`
- Plan: `Team`

Server

- Transport: Streamable HTTP (POST /mcp)
- Auth: OAuth 2.1 + Dynamic Client Registration; Entra ID as IdP; redirect allowlisted to Claude’s MCP callback
- Protocol posture: dual-era MCP handler with `legacy: 'stateless'` for 2025-era clients; Claude currently connects as legacy (`mcp_protocol_era: legacy` in our audits)
- Important: We do not keep an in-memory MCP session map for the Claude path. OAuth clients / refresh bindings live in DB and survive process restart. Successful next-day refresh_token confirms OAuth persistence is fine.
- Therefore this does not look like “server forgot the session object after restart.” It looks like the connector / conversation binding on the Claude side fails to re-open /mcp after overnight re-auth, while a new conversation forces a fresh MCP bind.

Controlled observations

- Broken: existing chat → OAuth refresh/DCR OK → tools do not reach /mcp.
- Working: new chat + connector reconnect → /mcp first → tools work.
- We suspect leaving the MCP process up overnight will not fully eliminate this, because access tokens still expire and Claude still re-runs refresh/OAuth; happy to retest and attach both audit windows if useful.

Related issues (not duplicates)

- Closest overnight/idle recovery cousin: [#795](https://github.com/anthropics/claude-ai-mcp/issues/795) (tools gone after long closure; differs because their refresh token is already expired — we still see a successful `refresh_token`, then no `/mcp` in the existing chat).
- Closest conversation-kill / recovery pattern: [#469](https://github.com/anthropics/claude-ai-mcp/issues/469) Defect 3 (`Session terminated` → need new chat / toggle connector).
- Session re-init after invalid session: [#450](https://github.com/anthropics/claude-ai-mcp/issues/450).
- **Not** the same as [#228](https://github.com/anthropics/claude-ai-mcp/issues/228) (refresh never attempted — ours succeeds).
- **Not** the same as [#479](https://github.com/anthropics/claude-ai-mcp/issues/479) (zero inbound requests / reachability — we receive OAuth/DCR traffic).
- **Not** the same as [#744](https://github.com/anthropics/claude-ai-mcp/issues/744) (revoked token → fast 401 on `/mcp` mislabeled as “server isn’t responding”; our failure is missing `/mcp` tool traffic after successful OAuth).
- Related Claude Code history (not primary tracker):
[#55970](https://github.com/anthropics/claude-code/issues/55970),
[#62008](https://github.com/anthropics/claude-code/issues/62008).

Please treat this as a conversation-scoped connector recovery bug: OAuth can succeed while the existing chat never re-binds MCP//mcp.