[Bug]: Command, skill, model and file search finds nothing when the query is typed on a non-Latin keyboard layout

[kirill-markin]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Switch the operating system input source to a non-Latin layout that is positionally based on US QWERTY. Russian, Ukrainian, Belarusian, Bulgarian, Serbian, Macedonian, Kazakh, Greek, Hebrew, Armenian, Georgian, Arabic, Persian and Thai layouts all qualify.
2. In the composer, type / and then press the keys that spell an existing command, for example the keys of model.
3. Repeat with $ and a skill name, with @ and a file name, with the Cmd+K command palette, and with the Settings search field.

Expected behavior

The menu finds the command, skill, model, file or setting. The keys pressed are the ones that spell its name on a US layout, and the names being searched are always Latin, so the intent is unambiguous.

Actual behavior

Every one of those surfaces shows an empty result. The composer menu reads "No matching command.", the palette and Settings search return nothing, and @ returns no files.

Nothing matches because the keystrokes produce the letters of the active layout while command names, skill names, model ids and file paths are Latin. The user has to notice the mismatch, switch input source, and retype. This affects every client surface and every one of the layouts above.

Impact

Minor bug or occasional failure

Version or commit

main at 01e05c1

Environment

Reproduced on macOS. The matching happens in shared client code and on the server's path search, so the behavior is the same on web, desktop and mobile, and independent of the operating system.

Additional context

I have a fix and will open a pull request referencing this issue.

[juliusmarminge]

Thanks for the clear repro. Confirmed: this is a real matching bug, not a shortcut or dead-key issue.

On a non-Latin layout that is positionally US QWERTY (Russian, Ukrainian, Greek, Hebrew, Arabic, Thai, and the others listed), the keys that spell a Latin identifier emit that layout’s letters. Command names, skill names, model ids, file paths, and Settings titles stay Latin. Every search surface compares the raw typed query to those names, so / shows “No matching command.”, $ / @ / the model picker / Cmd+K / Settings search all return nothing.

The shared scorer is packages/shared/src/searchRanking.ts (scoreQueryMatch / normalizeSearchQuery). Independent matchers have the same gap:

• Composer / and $: apps/web/src/components/chat/composerSlashCommandSearch.ts, apps/web/src/providerSkillSearch.ts
• Model picker: apps/web/src/components/chat/modelPickerSearch.ts
• Cmd+K: apps/web/src/components/CommandPalette.logic.ts (filterCommandPaletteGroups)
• Settings: apps/web/src/components/settings/settingsSearch.ts
• Mobile /, skills, and model picker: apps/mobile/src/features/threads/use-composer-command-menu.ts, composerSlashSkillSearch.ts, thread-settings-sheet-state.ts
• File trees / @ path search: apps/mobile/src/features/files/fileTree.ts, apps/server/src/workspace/WorkspaceEntries.ts

normalizeSearchText only does NFKD + lowercase. Shortcut physical-key fallback (apps/web/src/keybindings.ts, #4469) does not apply to typed search.

Not a wash of #2189 / #7995 / #4434 (shortcut bindings), #3142 (dead-key grave), or merged #4469.

Severity: minor but cross-client (web, desktop, mobile). Workaround today is switch to a Latin input source and retype.

Fix PR already open by the reporter: #11724. Next step is review that PR rather than a second implementation. Please keep Latin queries ranked above mapped ones, and leave Latin-script layouts (AZERTY, QWERTZ, Dvorak, Colemak) unmapped so ordinary English input is not rewritten.