[zhiru]

Problem

Linking a Claude (OAuth) account can fail with a generic "Internal server error" when the account is pinned to a proxy (proxy_assignments) that has gone dead. The OAuth code/token exchange and the provider connection test both run inside runWithProxyContext, whose T14 fast-fail throws PROXY_UNREACHABLE (503) when the pinned proxy can't be reached — with no fallback. Free-proxy pools go stale quickly, so a single dead egress silently breaks linking a new account, even though the upstream is reachable directly.

Observed in production logs:

[Proxy Fast-Fail] Proxy unreachable: http://<dead-proxy>:7890
Error testing connection: Error: [Proxy Fast-Fail] Proxy unreachable: http://<dead-proxy>:7890

Fix

Make control-plane operations degrade to a direct connection instead of throwing when the pinned proxy is unreachable:

• runWithProxyContext gains an opt-in directFallbackOnUnreachable. When the reachability check (or the ?family pre-check) fails, it logs a warning and runs the callback with the proxy context cleared (proxyContext.run(null, fn) → direct egress) instead of throwing.
• New runWithProxyContextOrDirect(proxyConfig, fn) wrapper applies it.
• Wire it into the control-plane flows only:
  • OAuth device-code / token exchange / refresh (/api/oauth/[provider]/[action])
  • provider connection test (/api/providers/validate)

Data-plane chat keeps strict pinning via the unchanged runWithProxyContext, so per-account egress-IP isolation is preserved where it matters. Control-plane reachability is prioritized over IP pinning — a dead pinned proxy must not block linking/validating an account.

Verification

• tests/unit/proxy-fetch.test.ts: throw-by-default on an unreachable proxy, opt-in fallback runs the callback directly, and runWithProxyContextOrDirect degrades to direct. node --test green.
• eslint + typecheck:core clean.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a fallback mechanism to direct connections when a proxy is unreachable or fails family pre-checks. It adds a new helper function runWithProxyContextOrDirect and updates control-plane operations, such as OAuth actions and provider API key validation, to use this fallback instead of throwing a 500 error. Additionally, unit tests have been added to verify this fallback behavior. I have no feedback to provide as there are no review comments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[diegosouzapw]

Thanks, @zhiru! 🙏 The control-plane / data-plane split is exactly right — OAuth code/token exchange, connection tests, and token refresh shouldn't surface a dead pinned proxy as an opaque 500, while chat keeps strict per-account egress-IP pinning. The runWithProxyContextOrDirect wrapper with the opt-in directFallbackOnUnreachable flag is a clean, backward-compatible shape, and the 3 TDD cases pin the behavior (throws by default / degrades with the opt / wrapper runs direct). All 8 proxy-fetch tests green. I added a small file-size baseline bump (+2). Merging into release/v3.8.26. 🚀