Summary
A project whose primary folder path contains a non-ASCII / Unicode character renders as empty in the Desktop sidebar (no sessions listed), even though the sessions exist in state.db with a cwd that correctly matches the project folder.
The backend (projects.tree / project_tree.build_tree) returns the sessions correctly — the project is only emptied in the Desktop UI layer, not in the data.
Reproduction (Windows 10, Hermes 0.18.2)
- Create a project whose primary folder path contains a Unicode letter, e.g. a folder literally named
bistånd (Swedish å) under D:\Projects\SV\.
- Open that project in the Desktop sidebar and start one or more chats there (so
state.db rows get cwd = D:\Projects\SV�istånd).
- Send a message (a
state.db row is created with that cwd).
- Open the Projects view.
Expected: the project lists its chats.
Actual: the project shows zero sessions, even though the same data renders fine for an ASCII-only sibling project.
Empirical evidence (from a real state.db + projects.db, no PII / no real paths shown)
Two projects, both with valid, matching cwd:
| project folder (normalized, case-folded) |
session cwd (normalized) |
backend match |
Desktop UI |
d:/projects/sv/bistånd |
d:/projects/sv/bistånd |
MATCH (True) |
EMPTY |
d:/sud/alimonyluxembourg |
d:/sud/alimonyluxembourg |
MATCH (True) |
shows sessions |
- The backend
project_tree._FolderIndex.match() uses Python casefold() over path segments, so the accented path matches correctly and build_tree returns the 2 sessions for the accented project.
- A sibling project with an ASCII-only path and identical structure shows its sessions normally.
- The only structural difference between the two projects is the Unicode letter
å (å) in the folder name.
Root-cause hypothesis
The Desktop/Electron renderer resolves and compares the project's folder path against session cwds using a path comparison that is not Unicode-normalization-safe (likely comparing the raw on-disk path / a differently-encoded variant of the accented name against the projects.db / state.db string). Because the two byte-strings never compare equal at the UI layer, the session-to-project grouping produces an empty lane — while the Python backend (Unicode-aware casefold) groups them correctly.
This is adjacent to #64629 (Windows D:\ vs D:/ normalization duplicate), but distinct: there the project appears twice; here an accented-path project appears empty despite a correct backend match. It is also distinct from #50438 (where cwd is NULL and never recorded) — in this case cwd is present and matches.
Suggested fix direction
Make the Desktop path-key comparison Unicode-normalization-form-stable (e.g. NFC/NFD normalize both sides, or compare via the same casefold/segment logic the backend uses) before grouping sessions into a project lane.
Related: #64629 (Windows path normalization), #50438 (TUI sessions not recording cwd).
Summary
A project whose primary folder path contains a non-ASCII / Unicode character renders as empty in the Desktop sidebar (no sessions listed), even though the sessions exist in
state.dbwith acwdthat correctly matches the project folder.The backend (
projects.tree/project_tree.build_tree) returns the sessions correctly — the project is only emptied in the Desktop UI layer, not in the data.Reproduction (Windows 10, Hermes 0.18.2)
bistånd(Swedishå) underD:\Projects\SV\.state.dbrows getcwd = D:\Projects\SV�istånd).state.dbrow is created with thatcwd).Expected: the project lists its chats.
Actual: the project shows zero sessions, even though the same data renders fine for an ASCII-only sibling project.
Empirical evidence (from a real
state.db+projects.db, no PII / no real paths shown)Two projects, both with valid, matching
cwd:cwd(normalized)d:/projects/sv/biståndd:/projects/sv/biståndd:/sud/alimonyluxembourgd:/sud/alimonyluxembourgproject_tree._FolderIndex.match()uses Pythoncasefold()over path segments, so the accented path matches correctly andbuild_treereturns the 2 sessions for the accented project.å(å) in the folder name.Root-cause hypothesis
The Desktop/Electron renderer resolves and compares the project's folder path against session
cwds using a path comparison that is not Unicode-normalization-safe (likely comparing the raw on-disk path / a differently-encoded variant of the accented name against theprojects.db/state.dbstring). Because the two byte-strings never compare equal at the UI layer, the session-to-project grouping produces an empty lane — while the Python backend (Unicode-awarecasefold) groups them correctly.This is adjacent to #64629 (Windows
D:\vsD:/normalization duplicate), but distinct: there the project appears twice; here an accented-path project appears empty despite a correct backend match. It is also distinct from #50438 (wherecwdis NULL and never recorded) — in this casecwdis present and matches.Suggested fix direction
Make the Desktop path-key comparison Unicode-normalization-form-stable (e.g. NFC/NFD normalize both sides, or compare via the same casefold/segment logic the backend uses) before grouping sessions into a project lane.
Related: #64629 (Windows path normalization), #50438 (TUI sessions not recording cwd).