[BUG] Claude Desktop 3P custom credential helper: `ConfigHealth` stuck in `provider_error` after cold-path helper auth succeeds

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When the credential helper needs to perform interactive OIDC login on app launch (cold path — no cached credential), Cowork's ConfigHealth probe runs before the helper returns. The probe fails, ConfigHealth transitions to provider_error, and the "Gateway returned an error … provider rejected a test request" banner is shown to the user — even though:

• The helper eventually returns a valid key (within the helper's TTL)
• Model discovery subsequently succeeds (Model discovery: 4 found in 7575ms; picker = 4 (discovery))
• The gateway is fully operational — messaging works immediately if the user dismisses the banner
• Clicking Check Again immediately transitions ConfigHealth back to healthy

The error state does not clear on its own when the underlying condition recovers. It only clears on explicit user action.

What Should Happen?

Any of the following (in order of preference):

1. Don't surface provider_error until after the helper's first successful return. Probe failures prior to that point are almost certainly helper-not-ready races, not real provider failures.
2. Auto-retry on provider_error once model discovery subsequently succeeds. The success signal is already being logged; wire it into ConfigHealth.
3. Hide the banner entirely when picker = N (discovery) with N > 0. A populated picker contradicts a provider error.

Error Messages/Logs

Cowork main log (timestamps CDT):


11:43:04 [custom-3p] 3P mode active { provider: 'gateway' }
11:43:04 [custom-3p] running helper { helperPath: '...\cowork-auth.exe' }
11:43:04 [custom-3p] running helper { helperPath: '...\cowork-auth.exe' }    <- fires helper twice
11:43:11 [custom-3p] helper ok (elapsed=7310ms stdoutBytes=25)
11:43:12 [custom-3p] Model discovery: 4 found in 7575ms; picker = 4 (discovery)
11:43:12 [custom-3p] helper ok (elapsed=7604ms stdoutBytes=25)
11:43:12 [custom-3p] ConfigHealth recomputed { state: 'provider_error', provider: 'gateway' }


Note `provider_error` is set **after** `Model discovery: 4 found` succeeds. ConfigHealth must be running a separate probe from model discovery, and that probe's failure result is cached across the recovery.

After user clicks **Check Again**:


11:45:43 [custom-3p] ConfigHealth recomputed { state: 'healthy', provider: 'gateway' }


No gateway config, no key, and no network path changed between 11:43:12 and 11:45:43 — only a user-triggered re-probe.

Steps to Reproduce

1. Configure Cowork in 3P gateway mode with a custom credential helper that performs OIDC interactive login on first run (ours: PKCE flow → token exchange Lambda → gateway key, ~7s end-to-end on cold path).
2. Ensure the helper's credential cache is empty (first-ever launch, or cache expired).
3. Launch Cowork.

Observed:

• Helper is invoked, spawns browser, completes OIDC flow, writes cache, returns key
• Cowork shows red "Gateway returned an error … Often a model-access or quota issue" banner
• Messaging works normally despite the banner
• Clicking Check Again clears the banner

Expected:

• No banner when the helper completes successfully and model discovery returns ≥1 model
• If an early probe fails, it should be retried silently once the helper returns, before surfacing any error UI

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z

Claude Code Version

NA

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Two related observations (possibly the same bug, possibly separate)

1. Helper invoked twice in parallel at launch.
[custom-3p] running helper fires twice within ~200ms. On cold path both helpers start a login flow; only fixed-port binding and a file-based mutex prevent double browser tabs. This seems unnecessary and amplifies the race — was this intentional?

2. ConfigHealth probe appears to run before helper completes.
Given the helper takes up to 120s in the worst case (OIDC timeout for slow MFA), any health probe that races it will look like a gateway failure. The probe should either:

a. Wait for the first successful helper return before probing, or
b. Suppress error UI until the probe has been retried after helper completion

<img width="791" height="350" alt="Image" src="https://github.com/user-attachments/assets/291a980a-aef1-4843-828a-355d77a27e42" />