fix(clients): the folder picker finds folders with accented names on macOS#29617

External image Minor · Functional Correctness · Quick win

Preserve literal prefix matches.

For De\u0301veloppement, the query De matched before this change. NFC normalization changes the entry prefix to Dé, so the folder now disappears. Preserve raw prefix matches alongside normalized matches.

✅ Confirmed as addressed by @saphid

Fixed in 1c700c21e8: the filter now keeps an entry when either its raw lowercased name starts with the raw query or its NFC-normalized name starts with the NFC-normalized query, so De matches the decomposed Développement again. Added that assertion to the existing test case; it fails without the fix.

@saphid The supplied code preserves raw prefix matches alongside NFC-normalized matches. This addresses the De regression without removing normalized matching. Thanks for adding the regression assertion.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Do not treat a normalized match as an exact path on every filesystem.

On Linux, Développement and De\u0301veloppement can be distinct paths. If only the NFD entry exists, CommandPalette submits exactBrowseEntry.fullPath and sets the action to “Add” instead of “Create & Add”. Preserve the typed path on normalization-sensitive filesystems, or require explicit selection of the suggested folder.

The NFC fallback is intentional for macOS, but filterFilesystemBrowseEntries has no filesystem-platform input and applies it to Linux targets as well.

✅ Addressed in commit 1c700c2

Keeping this as is. On Linux the NFC-typed name and an existing NFD folder are different folders, but they look identical, so treating the existing folder as the exact match ("Add") is the safer reading of what the user meant. "Create & Add" would make a second folder with the same visible name. When both spellings exist, a literal exact match still wins, and the existing test covers that.

@saphid Understood. The NFC fallback intentionally selects the existing folder instead of offering to create a visually identical folder. The code preserves literal-match precedence when both spellings exist. My finding treated that product choice as a defect. I withdraw it.

📝 Learnings were not changed: only organization members or users with write access to this repository can add or remove learnings.

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Data Integrity & Integration · Quick win

Apply NFC exact matching in the pinned browse path.

When pinnedCloneDirectoryName is set, the web browser uses filterPinnedBrowseEntries. That function takes visibleEntries from filterFilesystemBrowseEntries, so the NFD entry De\u0301veloppement is shown for the NFC query Développement. Its own exactEntry compares raw names only, so it returns null for that entry. The Add project path then falls back to the typed query instead of the browsed entry's path.

The non-pinned path through filterFilesystemBrowseEntries already matches NFC names exactly. Give the pinned path the same NFC fallback, after the literal match. The hidden-entry behavior stays unchanged.

Add a filterPinnedBrowseEntries test in apps/web/src/components/CommandPalette.logic.test.ts for an NFC query and an NFD folder name. On macOS, confirm that the typed NFC path is the intended Add project value when the entry is not an exact match.

✅ Addressed in commit d7c3a57

Confirmed and fixed in d7c3a5740f. In the clone-destination flow, filterPinnedBrowseEntries listed the decomposed entry but returned exactEntry: null, so Create & Clone used the typed path instead of the existing folder. Its exact match now follows the same rule as filterFilesystemBrowseEntries: it tries a literal namesMatch first, then compares NFC forms, and both steps still respect caseSensitive. I added an assertion to the existing filterPinnedBrowseEntries test. It failed before the fix with expected null to be { name: 'Développement', … } and passes now (36/36).

@saphid Thanks for confirming the fix in d7c3a5740f. Literal matching before the NFC fallback preserves match priority and caseSensitive behavior. The regression assertion covers the reported clone-destination failure.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Do not auto-select an ambiguous NFC fallback.

When multiple browse entries normalize to the query but no raw-name match exists, find selects the first entry. The typed-submit path then uses that entry’s fullPath, so it can operate on the wrong sibling directory. Accept the NFC fallback only when exactly one normalized entry matches.

✅ Addressed in commit 40c7a29

Good catch, fixed in 40c7a296de. The NFC fallback is now used only when exactly one entry normalizes to the query, in both filterPinnedBrowseEntries and the shared filterFilesystemBrowseEntries. A literal match still wins first. Each function's test now covers two folders (Å and Å) that both normalize to the typed Å. Those assertions failed before the fix and now return no exact match.

@saphid Thanks for the fix. The supplied code preserves literal-match priority and accepts the NFC fallback only when one entry matches. This addresses the ambiguity finding. The reported Å / Å regression cases cover the collision.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Restrict the NFC fallback to visible entries.

When the pinned clone name is a hidden dot-prefixed name, matching the pinned query sets visibleFilterQuery to "". The hidden entry is then excluded from visibleEntries, but the new fallback searches all browseEntries. An NFD hidden entry can therefore supply exactBrowseEntry.fullPath for an NFC query and become the clone destination even though it was not a visible browse choice. Keep the existing raw literal lookup unchanged; limit only the new normalized fallback.

Declining. On main, exactEntry intentionally searches all browseEntries, including hidden ones, not just visibleEntries. So a hidden pinned clone folder like .config already becomes the exact entry when its bytes match. The normalized fallback only treats NFD and NFC spellings of the same name as one name, so it should search the same set as that literal lookup. If it only searched visible entries, an existing hidden NFD folder would be missed while the same folder with NFC bytes would be found. Then the destination would depend on the folder name's Unicode normalization, which is the inconsistency this PR removes. Whether a hidden folder should ever be the clone destination is a separate question. It would change the literal lookup on main too.

@saphid You're right. The existing literal lookup searches all browseEntries, including hidden entries. Restricting only the normalized fallback to visibleEntries would make exact-entry lookup depend on Unicode normalization.

I withdraw this finding. The fallback should preserve the literal lookup’s scope, literal-match priority, and normalized-match uniqueness check. No change is needed for this finding.

📝 Learnings were not changed: only organization members or users with write access to this repository can add or remove learnings.

Review thread resolved.

_{You are interacting with an AI system.}