Kimi

Kimi authenticates from ~/.kimi on your host. In sync mode (the default), jackin’ copies the minimum Kimi state needed to make the container use the same account and model access you have on the host.

Logging in on the host

Before sync can forward anything, you need a working Kimi login on your host:

kimi login

Then verify that Kimi can start from the host shell:

kimi --version

Kimi writes its host-side state under ~/.kimi. jackin’ reads these files when sync is active:

Host path	How jackin’ uses it
~/.kimi/config.toml	Copied into the container’s /home/agent/.kimi/config.toml before Kimi starts. This is not the OAuth token store, but Kimi’s login flow writes the OAuth-backed provider, model, and service references here. A newly generated default config is empty and would not know which logged-in provider to use.
~/.kimi/credentials/	Copied into the container’s /home/agent/.kimi/credentials/ before Kimi starts. This directory contains the OAuth token files.
~/.kimi/device_id	Copied into the container’s /home/agent/.kimi/device_id before Kimi starts. Kimi includes this device id in OAuth/device headers.

jackin’ reads those host files but does not write back to them. If Kimi rotates or creates auth state inside the container, that state stays in jackin-managed instance storage for that container.

Runtime trust prompts

jackin’ launches Kimi with --yolo, so workspace-backed launches auto-approve Kimi actions instead of stopping on approval prompts. This applies only inside the jackin’ container runtime; jackin’ does not write Kimi settings on the host.

Models

Role authors can set a Kimi model in jackin.role.toml:

[kimi]
model = "kimi-k2"

When a model is set, jackin’ passes it to Kimi with --model at launch time. If the role omits a model, Kimi uses its own default model selection.

Modes available

Mode	Supported
sync (default)	Yes — forwards the Kimi config, OAuth credentials directory, and device id
api_key	Yes — injects KIMI_API_KEY
oauth_token	No — rejected at config time
ignore	Yes — no forwarding

In api_key mode, jackin’ removes any previously synced Kimi files from the auth handoff state and launches Kimi with KIMI_API_KEY from your operator env vars. In ignore mode, jackin’ removes the handoff state and forwards nothing.

See Agent Authentication for what each mode does and how to switch between them.

Troubleshooting

If Kimi inside the container shows “Not logged in” or cannot reach the selected model:

1. Check that the host login is active by running kimi --version and, if needed, kimi login on the host.
2. Open the Auth tab in jackin console and verify the effective mode for the (workspace × role × Kimi) cell.
3. If the container has stale credentials and the host has fresh ones, restart: jackin eject <role> && jackin load <role>.