[BUG] Desktop app splits session history across two different project folders for a path containing Korean (CJK) characters after an app update, making recent conversations appear lost
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Summary
After updating Claude Desktop, conversations from before the update (and, apparently,
from after it as well) stop showing up as "most recent" in the app's session picker,
even though nothing was actually deleted. On disk, the same conversation
(same sessionId) is split across two different project folders under~/.claude/projects/, whose folder names are hashed/derived from the working
directory path. The two folders differ only in how many - placeholder characters
appear where the Korean path segments are — consistent with the two app versions
normalizing the Unicode path differently (NFC vs. NFD) before deriving the folder key.
Environment
- OS: macOS 26.6.1 (Build 25G76)
- Claude Desktop: transcripts recorded from two versions,
2.1.222and2.1.229
(found via the version field inside the session's own JSONL records)
- Project working directory contains Korean characters, e.g.:
/Users/<user>/Desktop/회사/프로젝트/사내대시보드FR프로젝트
What I found on disk
Two project folders exist under ~/.claude/projects/, both containing a file with
the identical session id 6f6dcfc7-4c5f-4d88-b65d-81528a6f0037.jsonl:
| Folder (dash count differs) | Recorded app version | File size | Last modified | Last message |
|---|---|---|---|---|
| -Users-<user>-Desktop----------------------------FR--------- | 2.1.222 | 28,008,099 bytes | 2026-08-12 11:36:39 | a question from 2026-08-12 |
| -Users-<user>-Desktop---------------FR---- | 2.1.229 | 30,407,053 bytes | 2026-08-18 15:54:19 (still growing) | today's conversation, actively updating |
Both folder names decode to the same real path
(/Users/<user>/Desktop/회사/프로젝트/사내대시보드FR프로젝트), just with a different
number of - characters substituted for the non-ASCII (Korean) path segments.
The file in the first (older-version) folder stopped being written to at exactly the
moment the app appears to have been updated from 2.1.222 to 2.1.229. All messages
since then — including several full days of conversation — continued to be appended
correctly, but to the second folder instead of the first.
Impact
The app's "recent conversations" / resume picker appears to look up sessions by
re-deriving the project folder key from the current working directory at launch time.
If that derivation is not stable across app versions for paths containing non-ASCII
(e.g. CJK) characters, the picker can point at a stale folder that stopped being
updated on a prior version, making it look like every conversation since then
(including today's) was lost — even though the live, growing transcript is sitting
right next to it under a different folder name.
This is a data-loss scare, not actual data loss — but it's a serious trust issue:
a user restarting/updating the app has no way to tell, from the UI, that their recent
work is safe in a sibling folder rather than gone.
Suspected root cause
Unicode normalization mismatch (NFC vs. NFD) when hashing/slugifying the working
directory path to derive the ~/.claude/projects/<slug> folder name. macOS APFS/HFS+
historically returns Korean (and other CJK/precomposed) filenames in NFD from some
APIs and NFC from others; if the two app versions used different code paths to read
the cwd (or changed normalization handling in an update), the same real path hashes
to two different slugs.
Suggested fix
- Normalize the working directory path to a single canonical Unicode form (e.g. NFC)
before deriving the project folder key, consistently across app versions.
- On startup, if a normalization change is detected, migrate/merge any existing
project folder(s) that resolve to the same real path after normalization, rather
than silently starting a new one.
- At minimum, surface a warning in the UI when multiple project folders on disk
appear to map to the same real path, so users aren't misled into thinking work
was lost.
Steps to reproduce (best guess)
- Use a working directory whose path contains non-ASCII characters (e.g. Korean).
- Have an active/continued session in that project.
- Update Claude Desktop to a new version.
- Reopen the app in the same working directory.
- Observe: the "last conversation" shown may be from before the update, while a
new/duplicate project folder is silently created and used for all activity going
forward.
What Should Happen?
same as what's wrong
Error Messages/Logs
Steps to Reproduce
..
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.222
Claude Code Version
2.1.229
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_