Startup blocks blank for 15s on "Grove settings" fetch (/api/oauth/account/settings) when network is slow

Environment

• Claude Code v2.1.176, native install (~/.local/share/claude/versions/2.1.176, arm64)
• macOS (Darwin 25.5.0)
• Network: iPhone Personal Hotspot (relevant — see below)
• Logged in with a Claude Max account; project has claude.ai-connected MCP servers (github, read-ai)

Bug

On a fresh (non-nested) interactive start, Claude Code blocks before painting any UI on a network fetch of account settings — internally logged as "Grove settings" (GET /api/oauth/account/settings) — with a 15,000 ms axios timeout. On a flaky network (cellular hotspot, idle radio, slow DNS), that fetch stalls and the terminal sits completely blank for the full 15 seconds, then the UI appears and works normally.

Debug log from a slow run (claude --debug --dangerously-skip-permissions):

2026-06-12T22:45:00.380Z [DEBUG] [STARTUP] Loading MCP configs...
2026-06-12T22:45:15.441Z [ERROR] Failed to fetch Grove settings: AxiosError: timeout of 15000ms exceeded
2026-06-12T22:45:15.451Z [DEBUG] [STARTUP] MCP configs resolved in 33ms (awaited at +15071ms)

First UI paint happened at ~15.3 s, immediately after the timeout fired. Reproduced 4 times in a row in a PTY harness measuring time-to-first-paint; an identical launch a few minutes later (network warm) painted in 1.1 s.

Notes

• With plain claude (no --dangerously-skip-permissions) the MCP-server approval dialog can paint immediately, masking the stall; with the flag, nothing paints until the fetch resolves, so the user stares at a blank terminal.
• Nested sessions (CLAUDECODE=1 in env) don't hit this, which made it confusing to diagnose — it only affects fresh launches.
• curl/Node fetch to the same endpoint from the same machine were fast (<1 s) in good windows, so this is purely "slow network at the wrong moment", not a broken endpoint.
• Setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 appears (from the bundled code's data-residency|essential-traffic-only|no-auth handling) to skip the fetch, and is a usable workaround.

Expected behavior

Startup shouldn't hard-block first paint on a non-essential settings fetch. Render the UI first and apply the fetched settings when they arrive, or use a much shorter timeout / cached value with background refresh.