fix: send a key saved for a vLLM, Ollama or custom profile - #34

Summary

A vLLM, Ollama or custom profile with a saved key launched without it. These kinds default to auth = none, and every agent builder skips the key in that case, so alc config key <profile> stored a key that no launch sent - while alc config show still reported it as saved-local. Against a server started with an API key (vLLM or llama.cpp --api-key), alc -p <profile> opencode failed with "Invalid API Key" and alc -p <profile> codex with a 401.

• launch::build now treats a keyless-kind profile that has a key - saved, or read from its api_key_env - as bearer auth.
• One change at the single dispatch point: all eight agent builders use their existing keyed paths unchanged.
• A profile without a key launches exactly as before.

Validation

• Added regressions: a_key_saved_for_a_vllm_profile_is_sent fails on the previous implementation (no apiKey in the injected OpenCode config, no env_key for Codex) and passes with the fix; a_vllm_profile_without_a_key_still_sends_none guards the unchanged path.
• cargo fmt -- --check
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test --all-targets --all-features: 605 unit tests + 67 integration tests passed locally on macOS.
• End to end against a llama.cpp server that requires a key (Qwen3.8-27B over an SSH tunnel), from an isolated ALC_CONFIG_DIR with every key variable unset: alc -p brandy opencode run and alc -p brandy-codex codex exec both answered.

Local checks used DEVELOPER_DIR=/Library/Developer/CommandLineTools because the default Xcode installation requires license acceptance; no system configuration was changed.

Boundaries

No config schema change: a profile's stored auth stays none, and bearer applies per launch. alc config show and alc doctor are unchanged, since they already reported the key as saved. On released builds, alc config upsert <profile> --auth bearer is the workaround.

Found while testing against Qwen3.8 on llama.cpp, not addressed here:

• A Codex launch keeps the user's global model_reasoning_effort. max is valid for GPT models, but Qwen3.8's chat template rejects it with HTTP 500, which Codex reports as "high demand". A profile-level --effort medium avoids it.
• With --protocol responses, OpenCode (@ai-sdk/openai) fails with "text part ... not found" against llama.cpp's streaming /v1/responses; --protocol chat works.

🤖 Generated with Claude Code

https://claude.ai/code/session_015XwcLmZZ3eNrULtYBatTtZ