MCP server (Gitea) fails auth in Desktop app, connects immediately after resuming same session in Terminal app, no config changes

Description

An MCP server (Gitea MCP, project-scoped) fails to authenticate when called from the Claude macOS Desktop app — returning a connection/auth error — even though nothing about the token or MCP configuration has changed. Resuming the exact same session in the Claude Code Terminal app immediately resolves the issue and the same server works without any intervention.

This differs from #88758 (server never appears in /mcp at all on Desktop): here the server does connect, but fails auth on Desktop specifically, then succeeds with identical config once the session is resumed in the Terminal app. Reportedly not isolated to Gitea — the same pattern has been observed with other MCP servers in the same project.

Environment

• Claude Desktop app (macOS)
• Claude Code Terminal app (macOS)
• macOS: 25.6.0 (Darwin)
• Project uses a project-scoped Gitea MCP server (self-hosted Gitea instance)

Steps to reproduce

1. Start a session in the Claude Desktop app in a project with a project-scoped MCP server configured (e.g. Gitea).
2. Ask Claude to use that MCP server (e.g. list Actions runs).
3. Call fails with an auth/connection error (e.g. 401: invalid username, password or token).
4. Without changing any token, .mcp.json, or .claude/settings.local.json, resume the same session in the Claude Code Terminal app.
5. Ask Claude to retry the identical MCP call.
6. Call succeeds immediately.

Expected

MCP server authentication should behave consistently across host apps (Desktop vs. Terminal) for the same session and unchanged configuration/credentials.

Actual

Desktop app's MCP connection appears to use stale or improperly established auth state; the Terminal app's session-resume re-establishes the connection correctly with the same credentials.

Notes

• No config, token, or credential changes were made between the failed attempt and the successful one — only the host app changed (Desktop → Terminal, via session resume).
• This may share a root cause with #88758 (Desktop's MCP session bridge / "DO bridge" mechanism not behaving like the CLI's normal MCP loading path), but the failure mode is different enough (silent absence vs. connect-then-auth-fail) to warrant tracking separately.