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"Use this section to keep the next step practical before you touch accounts, files, infrastructure, or hardware.
| Check | Look for | Why it matters |
|---|---|---|
| Keep first | Identify sessions, config, plugins, logs, and credentials before removing an app or command. | Cleanup is safer when data deletion stays separate from uninstalling. |
| Confirm install source | Check whether the tool came from npm, pnpm, Homebrew, an app bundle, or a manual download. | The right removal path depends on the original channel. |
| Protect credentials | Do not display raw tokens or OAuth files while checking paths. | The goal is to remove risk, not expose secrets. |
| Verify after cleanup | Reopen a terminal and confirm PATH, config folders, and app entries behave as expected. | A clean uninstall needs evidence, not just a deleted file. |
| 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.