Windows: old kimi-code sessions not migrated to .kimi after upgrade; kimi migrate command missing

Windows: old kimi-code sessions not migrated to .kimi after upgrade; kimi migrate command missing

Summary

After installing/upgrading from the old kimi-code client to the new kimi 1.49.0 on Windows, old session data stored in %USERPROFILE%\.kimi-code was not migrated to the new data directory %USERPROFILE%\.kimi. The new client creates an empty session with the same session ID, which makes it appear as if all conversation history, todo lists, and background task state were lost.

Additionally, the kimi migrate subcommand documented in the official cheat sheet is not available in the installed 1.49.0 build.

Environment

• OS: Windows 10/11 (Git Bash available)
• New client: kimi 1.49.0, installed at C:\Users\happy\.local\bin\kimi.exe
• Old client: kimi-code, installed via uv at C:\Users\happy\AppData\Roaming\uv\tools\kimi-cli\
• New client info:
  • kimi-cli version: 1.49.0
  • agent spec versions: 1
  • wire protocol: 1.10
  • python version: 3.13.14

Steps to reproduce

1. Use old client kimi-code; data is written to C:\Users\happy\.kimi-code\.
2. Install/upgrade to new client kimi 1.49.0 at C:\Users\happy\.local\bin\kimi.exe.
3. Launch the new client.
4. Observe log lines:

   Session session_9cb81023-1ddb-4954-8461-94db0428dc3d not found, creating new session
   Resuming session: session_9cb81023-1ddb-4954-8461-94db0428dc3d
   

5. The session with the same ID exists in the new data dir, but is an empty shell:
   • state.json contains {"todos": []}
   • context.jsonl contains only the _system_prompt
   • No user/assistant messages, no todo list, no background task records.

Actual behavior

• Old session data is present in .kimi-code\sessions\... but is ignored by the new client.
• New session list shows an empty session with a confusingly identical session ID.
• Todo list and background task state appear lost.
• kimi migrate --help fails:

  PS> kimi migrate --help
  Usage: kimi [OPTIONS] [COMMAND] [ARGS]...
  Try 'kimi -h' for help.
  
  Error
    No such command 'migrate'.
  

Expected behavior

Any of the following would be acceptable:

1. On first launch, the new client detects %USERPROFILE%\.kimi-code and migrates sessions to %USERPROFILE%\.kimi.
2. At minimum, provide a working kimi migrate subcommand.
3. If migration is intentionally not performed, show a clear warning: "Old client data detected at .kimi-code but was not migrated. Use kimi migrate or manually archive the old directory."

Evidence that old data still exists

Old data is intact at:

C:\Users\happy\.kimi-code\sessions\wd_happy_f13ace9fd951\session_9cb81023-1ddb-4954-8461-94db0428dc3d\

Contents include:

• agents/main/wire.jsonl: 2341 lines total
  • llm.request: 315
  • usage.record: 311
  • context.append_message: 71
  • turn.prompt: 34
• agents/main/tasks/bash-*/output.log: 15 background tasks
• state.json: old title 0719·产Kimi·重建, last prompt 我输3次密码了没看到测试

Token usage from the old session:

• inputOther: 371,037
• output: 98,624
• inputCacheRead: 32,539,750
• Total: ~33,009,411 tokens

Impact

1. Productivity: The user must manually inspect old wire.jsonl to reconstruct task state.
2. Quota cost: Recovering context requires extra LLM calls. Even though most of the old tokens were cache reads, the recovery process itself consumes fresh quota.
3. Trust: After an upgrade, it looks like history was wiped. This is especially confusing because the session ID is reused but the data is empty.

Suggested fixes

1. Implement or restore kimi migrate on Windows.
2. On first run, detect ~/.kimi-code and either auto-migrate or print an explicit migration prompt.
3. After migration, print a summary: how many sessions were migrated, how many were skipped as empty, which config keys were dropped/renamed, and which credentials need re-login.
4. Provide a safe archive command (kimi archive-old-state) to avoid two long-lived state trees.
5. Consider surfacing per-session quota usage (kimi usage --by-session) so users can understand which sessions consumed quota during migration issues.

Compensation request

Because of this migration gap, I had to spend additional quota manually recovering session context from the old wire.jsonl and re-establishing the task state. I would appreciate a quota credit for the extra consumption caused by the missing migration tooling and misleading "empty session" UX.

If compensation is possible, please apply it to the Kimi Code account associated with this report.

Related issues

• #2437 — Migration Feedback: unclear state migration, quota attribution confusion, and possible agent quality regression

Official docs referenced

• Cheat sheet mentioning kimi migrate: https://www.kimi.com/id-id/resources/kimi-code-cheat-sheet
• Sessions and context guide: https://moonshotai.github.io/kimi-cli/en/guides/sessions.md

Start by reproducing the upgrade with data in %USERPROFILE%\.kimi-code and the empty session created in %USERPROFILE%\.kimi; inspect the CLI entry point for command registration and the session-data handling around kimi migrate. Done means old sessions are migrated or a clear actionable warning is shown, with migration results and skipped data reported; verify the command on Windows.