ACP auth gate (1.17+) blocks custom providers that don't need a Kimi account

ACP auth gate (1.17+) blocks custom providers that don't need a Kimi account

Summary

Since 1.17.0, the ACP server unconditionally requires a persisted Kimi account OAuth token for session/new, session/load, session/resume, and session/prompt (_check_auth in src/kimi_cli/acp/server.py). This applies even when the session would run entirely on a custom provider configured with a static api_key in config.toml — a setup that needs no Kimi account at all.

This contradicts the documented custom-provider behavior: the docs state that custom providers work with a configured API key, and the 1.x changelog notes "custom --config sessions keep their previous behavior". Over ACP there is currently no way to use a custom provider without first running kimi login.

Reproduction

mkdir -p /tmp/kimi-test/credentials
cat > /tmp/kimi-test/config.toml <<'EOF'
default_model = "zhipu/glm-5.3"

[providers."zhipu"]
type = "openai_legacy"
base_url = "https://open.bigmodel.cn/api/coding/paas/v4"
api_key = "sk-..."

[models."zhipu/glm-5.3"]
provider = "zhipu"
model = "glm-5.3"
max_context_size = 128000
capabilities = [ "thinking" ]
EOF

KIMI_SHARE_DIR=/tmp/kimi-test kimi acp
# initialize → ok
# session/new → -32000 Authentication required ("Run `kimi login` command in the terminal")

Tested on 1.49.0 and 1.50.0 (macOS arm64). The same config works fine in 0.40.1, where session/new succeeds and prompts run against the custom provider.

Expected behavior

For sessions whose configured/default model resolves to a custom provider with a static credential, the ACP auth check should not require a Kimi account login — e.g. skip _check_auth when config.default_model's provider carries a non-empty api_key, or scope the gate to Kimi-managed providers only.

Context

We embed kimi acp as a harness in a desktop client (with isolated config directories per session). Our users bring their own provider keys; requiring a Kimi account blocks that path entirely. Happy to provide more diagnostics if useful.

Start in src/kimi_cli/acp/server.py at _check_auth and trace how session/new, session/load, session/resume, and session/prompt resolve config.default_model and its provider. Run the supplied KIMI_SHARE_DIR reproduction with a static api_key in config.toml. Done means custom-provider ACP sessions work without kimi login while Kimi-managed sessions retain their authentication requirement.