bug: provision_llm_auth cross-provider scenarios unimplemented or incorrect

[kumaakh]

Problem

provision_llm_auth was written before multi-provider support was fully built. It likely assumes symmetric provider scenarios (Claude orchestrator provisioning Claude members, Gemini orchestrator provisioning Gemini members). Cross-provider scenarios — e.g. a Claude orchestrator provisioning a Gemini member, or a Gemini orchestrator provisioning a Claude member — have never been reviewed for correctness and may silently fail or use the wrong credentials.

Why it matters

With ~20 developers using fleet daily across mixed provider setups, cross-provider provisioning is a real and growing scenario. Silent auth failure mid-sprint is a hard-to-debug blocker.

Symmetric vs cross-provider

Symmetric (claude→claude, gemini→gemini): OAuth credential sharing works — both sides use the same provider's credential store. Likely already correct.

Cross-provider — needs research and implementation:

claude→gemini (and similar)

Three strategies to evaluate, in order of preference:

1. Local OAuth credential detection — check if the target provider's CLI is already authenticated on the member machine (e.g. Gemini CLI stores credentials at ~/.gemini/credentials.json or similar). If present and valid, no provisioning needed — just verify.

2. OOB API key collection — if no local credential is found, prompt the user via the apra-fleet auth --api-key OOB flow to enter the target provider's API key (e.g. GEMINI_API_KEY), store it via credential_store_set, and inject it into the member's environment before dispatch.

3. Pre-authenticated detection — before attempting any provisioning, probe whether the member's LLM CLI can already run successfully (e.g. gemini --version or a minimal test prompt). If it works, skip provisioning entirely. This handles cases where the user has already set up auth independently.

Other cross-provider combinations to cover

• gemini→claude
• gemini→codex / claude→codex
• gemini→copilot / claude→copilot
• Any orchestrator → any provider

What this issue should produce

1. Audit of current provision_llm_auth implementation per provider combination
2. Document which combinations work, which are broken, which are untested
3. Implement the three-strategy flow above for cross-provider cases
4. Tests covering at least the detection and OOB fallback paths

Related

• src/tools/provision-llm-auth.ts — primary file to audit
• src/cli/auth.ts — OOB input mechanism (already supports --api-key mode)