cloudflare-observability MCP OAuth token issued already-expired; refresh doesn't fire, forcing repeated re-auth

Environment

• Claude Code: 2.1.197
• cloudflare plugin: 1.0.0 (claude-plugins-official, commit 27ce0c0)
• macOS 26.5

Summary

The cloudflare-observability MCP server (https://observability.mcp.cloudflare.com/mcp) requires re-authentication almost every session, even though a refreshToken is present in the stored credentials. The other three Cloudflare MCP servers from the same plugin (cloudflare-api, cloudflare-bindings, cloudflare-builds) do not have this problem.

Evidence

Inspecting the OAuth tokens Claude Code stores in the macOS keychain (Claude Code-credentials → mcpOAuth), at the same point in time:

| Server | Token expiresAt |
|---|---|
| cloudflare-api | 2026-07-12 02:32 |
| cloudflare-bindings | 2026-07-12 02:32 |
| cloudflare-builds | 2026-07-12 02:32 |
| cloudflare-observability | 2026-07-11 12:12 |

The credentials keychain entry's own last-modified timestamp was 2026-07-11 15:12 — meaning the cloudflare-observability token was already ~3 hours expired at the moment it was last written. The other three servers got tokens valid ~11+ hours into the future from the same save. All four entries include a refreshToken, so a working refresh flow should silently renew cloudflare-observability before/at expiry — instead, /doctor and normal use report it as "needs authentication," requiring a full manual OAuth re-login.

Steps to reproduce

1. Authenticate the cloudflare-observability MCP server via /mcp.
2. Use Claude Code normally across a session or two (a few hours).
3. Run /doctor or invoke the server again — it reports "needs authentication" despite a stored refresh token that hasn't been used.
4. Repeat step 1 — it works briefly, then regresses again.

Expected behavior

Like the other three Cloudflare MCP servers in the same plugin, cloudflare-observability should either be issued a token with a comparable TTL, or Claude Code should transparently use the stored refreshToken to renew it before expiry, without prompting the user to re-authenticate.

Actual behavior

Token is issued already expired (or with an anomalously short TTL) relative to sibling servers in the same plugin, and refresh does not appear to occur, causing repeated forced re-authentication.