fix(aux): keep callable key_cmd credentials intact in all custom-provider resolution branches

[SiaoZeng]

What does this PR do?

Fixes the key_cmd crash class in agent/auxiliary_client.py (issue #88667) at all four call sites where a custom-provider credential is assumed to be a string:

• _resolve_custom_branch (bare custom, explicit key): .strip() on a CommandTokenSource raised AttributeError — this is the crash reported in [Bug]: callable api_key from key_cmd crashes custom-provider resolution with AttributeError #88667 (MoA) and observed via vision_analyze + agent.title_generator.
• _resolve_named_custom_branch (named custom_providers entry): same naive .strip() — not covered by fix(auth): keep callable api_key intact when resolving a custom provider #88668 / fix: preserve callable custom credentials across derived clients (vision et al.) #102244 / fix(auth): keep a callable key_cmd credential in the api_key branch #105595; it is the path that breaks vision/title/compression for every aux call on a key_cmd named provider.
• _resolve_api_key_branch explicit override: same .strip() (line also touched by fix(auth): keep a callable key_cmd credential in the api_key branch #105595).
• _resolve_custom_branch main-runtime reuse: str(main_runtime.get("api_key")) stringifies the token source, sending the object repr as the bearer — the Ollama capability probe sends the CommandTokenSource object repr as the bearer for key_cmd providers #104460 bug class, silent 401s instead of a crash.

The fix passes callables through uncalled and normalises only strings, mirroring the guard the main runtime already uses when it builds its credential dict (api_key.strip() if isinstance(api_key, str) else api_key if callable(api_key) else ""). The OpenAI SDK accepts a callable api_key per-request, and the Anthropic bearer-hook path routes callables to Authorization: Bearer (pinned by TestCallableKeyGetsBearerAuth), so nothing downstream needs to change.

Related Issue

Fixes #88667

Companion to the open PRs on the same issue: #88668 (bare custom only), #102244 (derived clients), #105595 (api_key branch only). Whichever lands first, the remaining branches still crash — this PR covers the full class in one pass; overlap is additive and mergeable.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/auxiliary_client.py — four callable()-guard passthroughs in the custom-provider resolution branches (no behaviour change for string credentials; blank-string handling preserved, no-key-required fallback unchanged).
• tests/agent/test_command_token_source.py — new TestExplicitCallableSurvivesCustomResolution class: three invariant tests asserting an explicit CommandTokenSource reaches _create_openai_client unchanged (not stripped, not stringified) on the bare-custom, named-custom, and main-runtime branches. RED on base per branch, all three green with the fix. Existing TestAuxiliaryResolverHonoursKeyCmd._resolve gained an optional explicit_api_key pass-through (no existing assertions touched).

How to Test

1. Configure any custom provider with a key_cmd (e.g. key_cmd: printf minted-token), run an aux task (vision/title generation) → before: AttributeError: 'CommandTokenSource' object has no attribute 'strip' in errors.log; after: aux call succeeds with a per-request bearer.
2. scripts/run_tests.sh tests/agent/test_command_token_source.py tests/agent/test_auxiliary_client.py → 236/236 pass.
3. New tests are RED on base (git stash the fix, run the file): one failure per covered branch.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate (fix(auth): keep callable api_key intact when resolving a custom provider #88668 / fix: preserve callable custom credentials across derived clients (vision et al.) #102244 / fix(auth): keep a callable key_cmd credential in the api_key branch #105595 each cover one call site; this covers all four — see above, overlap noted on [Bug]: callable api_key from key_cmd crashes custom-provider resolution with AttributeError #88667)
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass (targeted: the two files covering the touched code, 236/236 via scripts/run_tests.sh)
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.6 (Apple Silicon)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A (pure Python branch logic)
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

[alt-glitch]

This was generated by AI during triage.

Related: competing fixes for #88667: #88668 (earliest, _resolve_custom_branch), #105595 (_resolve_api_key_branch), #102244 (derived clients). This PR claims to cover the _resolve_named_custom_branch site the others miss; reviewers may want to consolidate.

[SiaoZeng]

Thanks for the triage note — checked against all three diffs, and the coverage picture is:

• fix(auth): keep callable api_key intact when resolving a custom provider #88668 guards the bare-custom explicit-key site only.
• fix(auth): keep a callable key_cmd credential in the api_key branch #105595 guards _resolve_api_key_branch only — the same line and the same callable() guard this PR adds there.
• fix: preserve callable custom credentials across derived clients (vision et al.) #102244 fixes the bare-custom and main-runtime sites via its helper functions, and additionally preserves callable credentials across derived/async clients (_sync_client_credential / _as_async_credential) — that async plumbing is genuinely valuable and this PR deliberately does not duplicate it.

What none of them cover is _resolve_named_custom_branch: every aux call (vision, title generation, compression) against a named key_cmd provider still raises AttributeError: 'CommandTokenSource' object has no attribute 'strip' with any one of those merged alone. This PR also un-stringifies str(main_runtime.get("api_key")) at the main-runtime reuse site — the silent-401 class from #104460.

Since all four branches raise the same crash class, whichever subset PR lands first leaves the remaining ones crashing. Suggesting consolidation into this PR (it has per-branch RED tests for all four sites) — but happy to defer to whichever shape maintainers prefer: I can rebase onto any of these landing first, and would gladly fold #102244's async-credential helpers in here if the maintainers want the async layer in the same pass.

[SiaoZeng]

Independent confirmation of this fix's premises, reproduced live on main @ 04dd80a with the pinned openai==2.24.0 (no network):

• OpenAI(api_key=<callable>) blanks .api_key to "" and stores _api_key_provider (openai/_client.py:142-147). agent/auxiliary_client.py:4329 (_to_async_client) reads only sync_client.api_key, so the AsyncOpenAI it builds carries an empty key — auth_headers == {}, i.e. async aux calls (vision, async auxiliary) against a key_cmd custom provider go out without an Authorization header. This is reachable in production via the named-custom branch (_named_custom_api_key resolves key_cmd to a callable → _create_openai_client → _route_client(async_mode=True) → _to_async_client).
• agent/auxiliary_client.py:4667: str(main_runtime.get("api_key") or "") on a callable yields the object repr as a truthy bearer — verified: client.api_key == '<agent.command_token_source.CommandTokenSource object at 0x...>'. The branch returns before the try_fn fallback loop, so it 401s with no fallback. Note the fallback loop at 4689-4697 already handles callables correctly, so the contract is known — only these two sites leak it.
• Test gap: no test in tests/ drives _to_async_client or the main_runtime reuse branch with a callable key (all key_cmd coverage is sync); one "callable survives async wrap" test, analogous to the existing Azure-Foundry sync test, would have caught both.

Suggest these three sites + a test be in this PR's scope; happy to see it land as-is.

[gweber]

Heads-up so work isn't duplicated: #109851 fixes the same _to_async_client credential drop by moving all token-provider handling (key_cmd, Entra ID) into one helper module, agent/api_credential.py, and pointing the sibling call sites at it. Your four resolve_provider_client branches are in there too, credited in the description, with regression tests. Happy to fold anything from this PR into that one, or to close mine if maintainers prefer this approach.

[ehz0ah]

Blocking: named custom providers still lose their configured extra_headers. The exact-head code builds the named custom OpenAI client with only query parameters and global user headers in _named_custom_openai_wire_client. It never applies custom_entry.extra_headers. _to_async_client then rebuilds the client and also does not preserve those configured headers. I verified a named provider with key_cmd and a required route header: the callable bearer survives, but the required header is absent from both the sync and async client requests. Providers that require proxy authentication or routing headers still reject these auxiliary calls. Please normalize and apply the named entry extra_headers when building the sync client, preserve the effective configured headers in the async conversion, and add sync plus async regression coverage. Also remove the extra blank line at the end of tests/agent/test_command_token_source.py so git diff --check passes.

[kshitijk4poor]

Landed as #114333 with Co-authored-by: SiaoZeng and a Credit: trailer (thank you, @SiaoZeng). Why not a cherry-pick: your _to_async_client rewrite is superseded by #113969 (merged today), the bare-custom hunk conflicts with the local-server-alias arm that landed since, and a fifth string-only site (the alias arm itself) needed the same guard — so the five sites now share one _normalize_api_key helper, with one parametrized test over the five shapes. @ehz0ah's extra_headers block is moot on current main after #113969. #114333 is armed to merge on green.