## `kimi acp` requires `--login` authentication and ignores `setting.toml` config — inconsistent with terminal auth behavior

[seventan1005-create]

What version of Kimi Code is running?

0.15.0

Which open platform/subscription were you using?

subscription

Which model were you using?

kimi-for-coding

What platform is your computer?

macOS (Apple Silicon)

What issue are you seeing?

When using kimi acp mode, authentication requires running kimi acp --login interactively. Configuring credentials in setting.toml (e.g. API Key) has no effect — ACP mode does not read these settings and still demands a fresh login.

What steps can reproduce the bug?

1. Configure a valid API Key / credentials in setting.toml
2. Run kimi acp to start ACP mode
3. ACP mode does not pick up the setting.toml configuration and requires kimi acp --login
4. Compare: running kimi directly (terminal mode) correctly reads the config and authenticates without interactive login

What is the expected behavior?

kimi acp should follow the same authentication logic as the terminal mode:

• If setting.toml contains a valid API Key, ACP mode should use it directly without requiring --login
• Alternatively, support non-interactive authentication methods (environment variables, config files) for ACP mode, consistent with the terminal mode

Additional information

This issue is particularly impactful when using agentline, which communicates with kimi-code over ACP in an automated, non-interactive setting. Since kimi acp --login requires manual interaction each time, it blocks use cases like background services, CI/CD pipelines, or any headless ACP integration.

Supporting config-file or environment-variable-based authentication in ACP mode would resolve this and bring parity with the terminal mode.

[ccrpc-fjunge]

I am running into the same / similar problem when attempting to use kimi-code with the Moonshot endpoint.

Running kimi in the terminal will correctly use the provider configured in settings.toml.
Running kimi acp requires oauth login with kimi.com, ignoring the provider settings in config.toml.

[tt-a1i]

I can take this. The ACP auth gate currently only treats OAuth tokens as authenticated. I'll keep the fix narrow so ACP also accepts a configured default model/provider with non-OAuth credentials, matching the normal CLI path.