Kimi Code data
A deeper Kimi Code removal guide for sessions, config files, OAuth credentials, plugin records, logs, and local history.
Removing the Kimi Code binary stops new sessions from launching, but it may not remove configuration, history, plugins, or OAuth tokens. If the goal is a complete local cleanup, work from the documented data-root layout.
The default data root is under the user's home directory unless KIMI_CODE_HOME points elsewhere. Clear it in pieces when you only need to fix one part.
A full removal is easier when you separate the executable, the data root, plugins, and credentials.
KIMI_CODE_HOME wins when it is set; otherwise Kimi Code uses the default home directory.
K3NovaKIMI_CODE_HOME="${KIMI_CODE_HOME:-$HOME/.kimi-code}"
printf '%s\n' "$KIMI_CODE_HOME"
ls "$KIMI_CODE_HOME"
ls "$KIMI_CODE_HOME/credentials" 2>/dev/null || true
ls "$KIMI_CODE_HOME/plugins" 2>/dev/null || trueExport a session and validate config while the command still works.
mkdir -p "$HOME/kimi-code-backup"
kimi export -y -o "$HOME/kimi-code-backup/latest-session.zip"
kimi doctorUse this when only plugin records or logs are causing trouble.
KIMI_CODE_HOME="${KIMI_CODE_HOME:-$HOME/.kimi-code}"
STAMP="$(date +%Y%m%d-%H%M%S)"
TARGET="$HOME/kimi-code-backup/selected-data-$STAMP"
mkdir -p "$TARGET"
test -d "$KIMI_CODE_HOME/plugins" && mv "$KIMI_CODE_HOME/plugins" "$TARGET/plugins"
test -d "$KIMI_CODE_HOME/logs" && mv "$KIMI_CODE_HOME/logs" "$TARGET/logs"After reinstalling, test config first and then run one tiny prompt.
kimi doctor
kimi -p "Reply only: KIMI_READY"Copy this prompt into Kimi Code, K3Nova, or another AI agent. Keep approval manual for file writes, shell commands, account actions, and secrets.
Use this to give the agent the task and safety boundary in one message.
You are my AI agent for this task: separate the Kimi Code executable from local data, credentials, sessions, logs, and plugin records before any cleanup.
Start by restating the goal and the permissions you need.
Use official docs or the files I provide before making claims.
Give me a direct answer first, then a short table or checklist.
If commands are needed, show exact copyable commands without a shell prompt.
Ask before writing files, running shell commands, deleting or moving data, logging in, spending money, changing account settings, or handling API keys.
Stop and ask me when a step requires secrets, payment, account access, destructive cleanup, or a permission broader than the task.| Permission | Give AI | Why |
|---|---|---|
| Inspection | Allow Read, Grep, Glob, and package-list commands. | The agent needs to find how Kimi Code was installed. |
| Backups | Ask before creating or moving backups. | Backup location and size should be visible. |
| Uninstall or move | Ask before npm, pnpm, yarn, mv, rm, rmdir, or credential cleanup. | Removal can be hard to undo. |
| Credentials | Deny reading or printing OAuth files, API keys, and MCP credentials. | The agent can describe paths without exposing secrets. |
| Data type | Where to look | Use when |
|---|---|---|
| Runtime config | config.toml in the data root | Provider, model, or loop settings are wrong |
| Sessions | sessions and session_index.jsonl | You need a full conversation reset |
| Provider OAuth | credentials | Login state is wrong or should be removed |
| Plugin records | plugins | Plugin state is broken or unwanted |
Check KIMI_CODE_HOME first. If it is not set, use the default Kimi Code data directory documented for your operating system.
Use kimi export for sessions you may need to share or archive before deleting session folders.
Reset config, sessions, logs, provider credentials, MCP credentials, plugin records, or user skills depending on the problem.
After cleanup, install Kimi Code again and run a small command before restoring plugins or custom config.
Kimi Code keeps provider credentials and MCP credentials in separate locations. Clearing one does not necessarily clear the other.
Removing plugin records resets installed state. Local plugin source directories are not automatically deleted, which is useful when you want to reinstall later.
Deleting config.toml is enough for many provider or model mistakes. Deleting the whole data root is the last step, not the first one.
No. It is useful for a full reset, but targeted deletion is safer for most problems.
Not necessarily. Existing config can survive package reinstall unless you clear the data root.
Export important sessions and copy any config you may need to compare later.