fix(aux-client): honor api_mode in explicit_base_url path; read key_env in task config (#16254)

[briandevans]

Summary

• Fixes the remaining broken code path (path 3) in agent/auxiliary_client.py where api_mode: anthropic_messages was silently ignored when explicit_base_url was set
• Fixes key_env being silently dropped from auxiliary.<task> configs, causing 403 errors even when the env var was set

The bugs

resolve_provider_client() has three independent branches that each construct an SDK client from (base_url, api_key, api_mode):

#	Path	Triggered by	api_mode dispatch	Status
1	_try_custom_endpoint (~L1177)	OPENAI_BASE_URL env	inline if custom_mode == "anthropic_messages":	✅ fixed by #7648
2	named-custom branch (~L1895)	provider: myrelay + providers.myrelay dict	inline if entry_api_mode == "anthropic_messages":	✅ fixed by #15059
3	explicit-base-url branch (~L1850)	auxiliary.<task>.base_url flowed via explicit_base_url	none — always built plain OpenAI client	❌ this PR

Path 3 result: Anthropic-format body sent to <base_url>/chat/completions (OpenAI endpoint) instead of /v1/messages, returning 404 invalid_model or 403.

Bug 2 — _resolve_task_provider_model() parsed api_key from task config but had no equivalent for key_env. Result: auxiliary task configs that specify key_env always sent api_key="no-key-required", producing 403 even when the env var was set. (Contrast with path 2's _get_named_custom_provider() which correctly reads key_env.)

The fix

Path 3: added the same if api_mode == "anthropic_messages": dispatch block that path 2 has at L1895-1914 (lines 1856-1878 here). Updated the explicit_base_url docstring to remove the hardcoded "OpenAI-compatible" assumption.

key_env: added two-line os.getenv(_cfg_key_env) resolution in _resolve_task_provider_model, mirroring _get_named_custom_provider.

Test plan

• Before: test_explicit_base_url_anthropic_messages_returns_anthropic_client fails (isinstance(client, AnthropicAuxiliaryClient) → False, got OpenAI-wire client)
• After: 7 new tests all pass; 95 existing auxiliary client tests unchanged
• Regression guard: reverted path 3 block → observed assertion failure; restored → 0 failures
• key_env: test_resolve_task_provider_model_reads_key_env confirms env var is now resolved; test_resolve_task_provider_model_api_key_wins_over_key_env confirms precedence

Related / Positioning

• Fixes [Bug]: 'custom = OpenAI' hardcoded assumption: explicit_base_url path ignores api_mode (sibling of #7661/#15033, plus key_env never parsed in aux config) #16254
• Completes the api_mode dispatch coverage started by fix(aux): honor api_mode for custom auxiliary endpoints #7648 (path 1) and fix(aux-client): honor api_mode: anthropic_messages for named custom providers #15059 / Named custom providers with api_mode: anthropic_messages fail with 404 in auxiliary tasks #15033 (path 2); those PRs only fixed their respective code paths — path 3 was still broken on HEAD 755a2804
• PR fix(runtime_provider): handle provider='custom' with explicit base_url in ACP sessions #13831 (ms-alan) addresses explicit_base_url in ACP sessions specifically; this PR addresses auxiliary.<task> configs via _resolve_task_provider_model → resolve_provider_client with explicit_base_url

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Fixes auxiliary client configuration handling so api_mode and key_env are honored when auxiliary tasks use an explicit per-task base_url (the “explicit_base_url/path 3” code path).

Changes:

• Updated resolve_provider_client() to route explicit_base_url + api_mode="anthropic_messages" through the Anthropic Messages client wrapper (instead of always building an OpenAI-wire client).
• Updated _resolve_task_provider_model() to resolve key_env from the environment when api_key is not provided in auxiliary.<task> config.
• Added a focused test module covering the path 3 Anthropic dispatch and key_env behavior/precedence.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
agent/auxiliary_client.py	Honors api_mode="anthropic_messages" for explicit_base_url custom endpoints; resolves key_env in task config.
tests/agent/test_aux_client_path3_anthropic.py	Regression tests for path 3 Anthropic routing and key_env resolution/precedence.

Comments suppressed due to low confidence (1)

agent/auxiliary_client.py:1706

• The updated docstring still documents api_mode as only {"chat_completions", "codex_responses", None}, but this function now (and elsewhere in the file) supports "anthropic_messages" as well. Please update the api_mode docstring to include anthropic_messages so callers configuring explicit_base_url aren’t misled about supported values.

        explicit_base_url: Optional direct endpoint URL. The SDK client
            selected is determined by api_mode (OpenAI, Anthropic, Codex).
        explicit_api_key: Optional API key paired with explicit_base_url.
        api_mode: API mode override.  One of "chat_completions",
            "codex_responses", or None (auto-detect).  When set to
            "codex_responses", the client is wrapped in
            CodexAuxiliaryClient to route through the Responses API.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

In the explicit_base_url + api_mode="anthropic_messages" branch, query parameters are stripped into _dq but then discarded for the Anthropic client: build_anthropic_client() is called with _clean_base and the wrapper stores _clean_base. This diverges from _try_custom_endpoint() (which passes the original custom_base) and can break endpoints that require query params (e.g. Azure api-version) or any custom query-based routing. Consider preserving the original URL semantics for Anthropic mode (either pass the original URL consistently, or plumb the extracted query into the Anthropic client creation).

[briandevans]

@copilot Finding addressed in commit 91644463:

The inline comment correctly identified that _clean_base (query params stripped) was being passed to build_anthropic_client instead of custom_base (original URL). build_anthropic_client already handles query params internally — specifically, it routes Azure api-version via default_query rather than appending it to base_url — so passing _clean_base dropped those params before the function could process them.

Fixed by passing custom_base in both the build_anthropic_client call and the AnthropicAuxiliaryClient constructor, mirroring what path 2 (named custom providers, line 1898) has always done correctly.

Added a regression test (test_explicit_base_url_query_params_preserved_for_anthropic_client) that verifies the original URL including query params reaches build_anthropic_client.

[briandevans]

Closing to keep the queue clean — happy to reopen if this is still useful.