Session history lost when adding/removing folders in multi-root workspace

[wei4j]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

Windows 11

Kiro Version

1.0.0

Bug Description

In a multi-root workspace, session history is lost whenever a folder is added to or removed from the workspace, even though the workspace name itself remains unchanged.

It appears that Kiro associates session history with the exact set of workspace folder paths rather than the workspace identity (i.e., the .code-workspace file name or an internal workspace ID). This means any structural change to the workspace — adding a new project folder or removing one — causes all previous session history to disappear.

Steps to Reproduce

1. Open a multi-root workspace (.code-workspace file) containing folders A, B, and C.
2. Have several Kiro sessions with conversation history.
3. Add a new folder D to the workspace (or remove an existing folder).
4. Observe that all previous session history is gone — no prior conversations are listed.

Expected Behavior

Session history should be associated with the workspace identity (e.g., the workspace name or the .code-workspace file path), not the exact list of folder paths within the workspace.

Adding or removing folders from a multi-root workspace should NOT cause existing session history to disappear. Users frequently adjust which project folders are included in a workspace without intending to lose their conversation history.

Conversation ID

No response

Additional Context

This is particularly disruptive for users who work with multi-root workspaces as their primary development setup. Multi-root workspaces are dynamic by nature — project folders are added/removed as work shifts between projects. Losing all session history each time this happens makes it very difficult to reference prior conversations.

Suggested fix: Use the workspace name (or .code-workspace file path) as the key for session history association, rather than a hash or composite of the contained folder paths.

[github-actions]

🤖 Potential Duplicate Detected

This issue appears to be similar to:

• #9589: Lost all context (85% similar)
• #9485: Sessions/chat history hidden after update: existing sessions not re-keyed to new workspace-path scheme (85% similar)
• #7320: Kiro (Latest Version) on Windows: Frequent "Remote Extension Host Terminated Unexpectedly" Error with Open Remote SSH Connection to Debian 13.1 Server, Causing Session Reset & Chat History Loss (85% similar)
• #9472: Chat history missing from sidebar after update — older sessions not listed (session format/path migration not applied) (82% similar)

What happens next?

• ⏰ This issue will be automatically closed in 3 days
• 🏷️ If this is not a duplicate, you can prevent automatic closure by adding a comment or reacting with 👎 to this message.
• 💬 Comment on the original issue if you have additional information

Why is this marked as duplicate?
Both issues report loss of session history/context, though the new issue specifically identifies multi-root workspace folder changes as the trigger while #9589 reports general context loss

[wei4j]

This is NOT a duplicate. Please review more carefully.

The issues flagged as potential duplicates (#9589, #9485, #9472, #7320) are all about session history lost after a Kiro version upgrade — the session storage path/key changed between versions, causing old sessions to become invisible. That is a one-time migration issue.

This issue is fundamentally different:

• Root cause: Session history is keyed by the exact set of workspace folder paths, not by workspace identity (.code-workspace file).
• • Trigger: Adding or removing ANY folder in a multi-root workspace causes ALL session history to disappear — this happens every time the workspace structure changes, not just during upgrades.
• • • Reproducibility: 100% reproducible on demand, not a one-time event.
      This has a severe impact on my daily work. I work exclusively in multi-root workspace mode, and workspace folder composition changes frequently as I shift between projects. Every time I add or remove a project folder, I lose access to all prior Kiro session history. This means I cannot reference previous conversations, decisions, or context — which is critical for complex, ongoing development work.

The suggested duplicates describe a different symptom (upgrade-triggered loss) with a different fix path (migration of old session keys). This issue requires Kiro to change how it identifies a workspace — using the .code-workspace file path or workspace name as the session key, rather than a hash of contained folder paths.

Please remove the duplicate label and re-triage. Thank you.

[github-actions]

Thank you for your feedback! 🙏

The duplicate label has been removed and this issue has been sent back for maintainer review.

A maintainer will review this issue shortly.

[bborgald]

Adding some reverse-engineered detail from a Windows 11 / 1.0.0 install, in case it helps localize the fix. Your root-cause guess is right, with one extra wrinkle that makes a key-only fix insufficient.

Storage model (verified on disk). Each session lives at %USERPROFILE%\.kiro\sessions\<workspaceHash>\<sessionId>\ with session.json (metadata, including a workspacePaths[] array) and messages.jsonl.

The key is a hash of the sorted folder paths (reverse-engineered, reproduces every bucket on my machine exactly):

workspaceHash = sha256("\0".join(sorted(p.lower().replace("\\","/") for p in folders))).hexdigest()[:16]

So the bucket is keyed by the folder-path set, not the workspace identity. Add or remove one folder and the hash changes; the history panel reads only the bucket for the current set, so prior sessions sit in a different bucket and look gone. Revert the folder set and the old hash returns and history reappears. Nothing is deleted, it is purely a lookup-key problem, which matches your suggested fix.

The extra wrinkle (this is the part that bit me). After the folder set changes, the panel often stops issuing the list query at all. The extension logs [SessionPersistence] Listed N session(s) for workspace <hash> whenever it lists. On my machine that line appeared the last time history worked, then across the restarts after the folder-set change it logged only Initialized persistence at ... and never another Listed .... Implications when validating a fix:

• Reverting the folder set did not reliably bring the list back within a running window; it took a full quit and relaunch (not "Developer: Reload Window").
• Manually copying the session folders into the new bucket did NOT make them appear, because the panel was not re-scanning. So this is not only a wrong-key problem, the list query also needs to re-fire on a workspace folder-set change.
• Adding a folder to an already-running window is split-brain: the session writer keeps writing under the old hash while the panel recomputes the new hash, so the active session lands in the old bucket while the panel shows the new empty one.
• The list path itself (bucket scan plus a permissive parse of each session.json) is not the blocker; old-schema sessions parse fine. The blocker is the key plus whether the query fires, not schema validation.

Suggestions:

1. Key session history on a stable workspace identity (the .code-workspace path/id), falling back to the folder path for single-folder windows.
2. Re-issue the list query whenever the workspace folder set changes (including a live folder add/remove), so the panel does not get stuck not listing.
3. Provide a back-compat path so sessions stored under the old folder-set hash still surface after the key changes, e.g. on a miss, also scan buckets whose session.json.workspacePaths is a subset/superset of the current set, or index by workspacePaths.

[machcnz]

The issue aside, loss of chat history which is a pain and isnt being taken seriously, the entire ticket reads like bot's talking to bots.

Interesting how bots give MS/GH an appearance of 'ticketing' or 'support', however the reality is issues go unactioned for months to years, great products are not where the cash-flow is.

Could this be a reason MS is unable/unwilling to Automate remediation with bots/"AI" - because code quality doesnt seem to be one of the reasons not to.

[AnilMaktala]

Thanks for reporting this and sorry for the trouble. You're running Kiro version 1.0.0, and we've shipped several patch releases since then with targeted fixes:

• 1.0.52 (Jul 2): Compaction fixes, session migration, permissions/MCP reliability
• 1.0.89 (Jul 3): Session restore, performance, hooks/steering fixes
• 1.0.116 (Jul 9): Hooks on agent writes, lazy MCP OAuth, connectivity fixes
• 1.0.138 (Jul 13): Compaction loop fix, PowerShell trust, MCP network recovery

Could you please retest on the latest version (1.0.138) from https://kiro.dev/downloads and let us know if this is still an issue? If we don't hear back within 7 days, we'll assume it's resolved and close this out.