Proposal: Persist chat history when renaming a workspace directory

[deyil]

Hi Kilo Code team,

I’d like to request a feature (or confirm intended behavior) regarding chat history persistence when a workspace directory is renamed.

Issue faced

• Context: Working with Kilo Code discussions/agent chats tied to a local workspace directory.
• Action: Renamed the workspace’s root folder (e.g., from project-alpha to project-alpha-v2).
• Result: The chat history and context associated with the original directory no longer appeared under the renamed workspace. Effectively, it looked like a new workspace with no prior conversation history.
• Impact: Lost continuity for in-progress code reviews and action items referenced in the agent chat. This disrupts workflow, especially during iterative refactors or when following a naming convention update across projects.

Likely cause (assumption)

It seems the chat store is keyed by an absolute or relative path that changes when the directory name changes, without an alias/ID indirection. If the chat association relies on the path alone, renames will break the link.

Suggested implementation

• Stable workspace ID:
  • Generate and store a persistent workspace UUID (e.g., in a dotfile at the workspace root or inside the Kilo metadata directory).
  • Use this UUID as the primary key for chat threads instead of the filesystem path.
• Path tracking and migration:
  • Maintain the last-known path alongside the UUID.
  • On load, if the folder contains the same UUID but at a new path, auto-migrate/reattach the existing chat history.
• Backward compatibility:
  • On first open post-rename, if no UUID is found but previous chat history exists indexed by the old path, prompt the user to link the new path to that history.
• UI/UX improvements:
  • Add a “Reattach chat history” action in the command palette/settings when a mismatch is detected.
  • Provide a visible indicator when a workspace’s path changed and history was successfully remapped.
• Export/backup:
  • Offer an explicit “Export/Import workspace chat” to JSON for manual recovery across path changes or machine migrations.
• Multi-root/multi-folder:
  • If the same workspace is opened from different machines/paths (e.g., synced via Git), let the UUID unify the chat history while storing per-machine path metadata.

Questions

1. Is the current behavior by design (path as the key), or should history already persist across renames?
2. If this is not yet implemented, would you consider the UUID-based approach above?
3. Any recommended interim workaround (e.g., copying a metadata file or manually editing an index to point to the new path)?

Thanks for reviewing. Persisting chat history across directory renames would significantly improve continuity for iterative development and refactor-heavy workflows.

Sources

[alpapan]

second that: it's kinda crucial when working on multiple computers (desktop and laptops) or windows11 and wsl and you want to have a task per project rather than globally in the user's settings...

[petiteoffense]

Thirded. I'm having a bear of a time trying to figure out if there's any way I can hack together a migration of chat history to another device. The chat context is so important and represents hundreds of hours of work. It's so critical to be able to hold onto it.