[Bug] Intermittent subagent launch failure: OAuth token fetch to auth.kimi.ai times out

Summary

Launching subagents intermittently fails with an OAuth connect timeout to auth.kimi.ai, even though the user is fully authenticated and the main session works fine. Retrying the same launches eventually succeeds. A transient auth-endpoint hiccup currently kills the whole subagent spawn and burns tokens on retries.

Environment

• Version: 2.0.0
• OS: Linux
• Auth: signed-in session (kimi.com account)

What happened

Dispatched 3 parallel subagents via the Agent tool. All 3 failed immediately, before doing any work:

subagent error: The subagent was stopped before it finished. Reason: OAuth request to https://auth.kimi.ai/api/oauth/token failed: fetch failed: Connect Timeout Error (attempted address: auth.kimi.ai:443, timeout: 10000ms)

• 1st attempt: 3/3 subagents failed with the error above.
• Resume/retry of the same subagents: 2/3 failed again with the identical error.
• 2nd retry: all 3 launched and completed successfully.

The failure is not deterministic and does not correlate with the prompt content — the same prompts succeeded on retry.

Expected behavior

• Token fetch for subagent spawns should retry with backoff (and/or reuse the already-valid cached session token instead of re-fetching per spawn).
• A transient connect timeout to the auth endpoint should not abort the entire subagent launch; a single retry inside the harness would have recovered in all observed cases.
• Failed-before-start subagents should ideally not consume quota for prompt preparation.

Actual impact

• Wasted tokens: each failed launch and each resume re-processes the (large) subagent prompts. In this session roughly 5 subagent launches failed and had to be retried/resumed.
• User-facing flakiness: parallel swarm dispatches are especially affected (N parallel OAuth fetches seem to hit the timeout more often).

Suggestions

1. Add retry with exponential backoff + jitter around the OAuth token fetch (at least 2–3 attempts, timeout > 10s or configurable).
2. Cache the OAuth token per session and share it across subagent spawns instead of fetching per launch.
3. Consider fetching the token lazily once per batch when dispatching multiple subagents in parallel.

Happy to provide logs/session ids if helpful.

No source file or test is named. Start from the subagent launch path and its OAuth token fetch to auth.kimi.ai; reproduce the intermittent timeout with parallel launches and trace how failed-before-start work is handled. Done means transient token-fetch failures recover without aborting launches and successful retries do not require users to resume subagents.