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.
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, andsession/prompt(_check_authinsrc/kimi_cli/acp/server.py). This applies even when the session would run entirely on a custom provider configured with a staticapi_keyinconfig.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
--configsessions keep their previous behavior". Over ACP there is currently no way to use a custom provider without first runningkimi login.Reproduction
Tested on 1.49.0 and 1.50.0 (macOS arm64). The same config works fine in 0.40.1, where
session/newsucceeds 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_authwhenconfig.default_model's provider carries a non-emptyapi_key, or scope the gate to Kimi-managed providers only.Context
We embed
kimi acpas 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.