Steps to reproduce
- Use a keyboard where the
,key sits at the physical USKeyMposition — a French AZERTY board. (Reproducible on any keyboard by setting the input source to French, then pressing the physicalMkey.) - Set the macOS input source to French.
- Press
⌘+ the key that produces the,character.
Did you follow the troubleshooting guide? [Y/N]
Y — reproduces in the sandbox vault (default theme, no community plugins, no CSS snippets). The menu flashes and the Settings modal does not appear, identically to the main vault.
Expected result
The Settings modal opens, as it does when clicking Obsidian → Settings… or running Open settings from the command palette.
Actual result
The Obsidian menu title flashes in the menu bar. No modal opens. Nothing else happens.
The keystroke never reaches the renderer, so the Hotkeys recorder cannot capture ⌘+, either — the default binding is unreachable and unassignable.
Environment
SYSTEM INFO:
Obsidian version: 1.12.7
Installer version: 1.12.7
Operating system: Darwin Kernel Version 25.5.0: Tue Jun 9 22:18:58 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6000 25.5.0
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
Keyboards and layouts in use:
- External Apple Magic Keyboard, French AZERTY — used with the French input source
- MacBook built-in keyboard, Canadian QWERTY — used with the Canadian QWERTY input source
Physical key positions on the AZERTY board:
| Key label | Physical position (KeyboardEvent.code) |
Character under French layout |
|---|---|---|
, |
KeyM |
, |
; |
Comma |
; |
The bug occurs only under the French input source.
Additional information
Console capture
A capture-phase listener registered in the developer console, so it runs before any application handler and cannot be suppressed by stopPropagation():
window.addEventListener('keydown', e =>
console.log(JSON.stringify({key: e.key, code: e.code, keyCode: e.keyCode, meta: e.metaKey, ctrl: e.ctrlKey, alt: e.altKey, shift: e.shiftKey})), true);
French layout, AZERTY board, focus in the editor:
| Keypress | Logged event |
|---|---|
⌘ + key labeled , |
{"key":"Meta","code":"MetaLeft","keyCode":91,"meta":true,...} — no event for the comma key itself |
⌘ + key labeled ; |
{"key":";","code":"Comma","keyCode":186,"meta":true,...} |
key labeled , alone |
{"key":",","code":"KeyM","keyCode":188,"meta":false,...} |
key labeled ; alone |
{"key":";","code":"Comma","keyCode":186,"meta":false,...} |
Both unmodified keys reach the renderer normally, and ⌘ + the ; key arrives intact. Only ⌘ + the , key disappears entirely before any JavaScript runs. These results were captured in both the main vault and the sandbox vault, with identical output.
Hotkeys recorder
Settings → Hotkeyslists⌘ ,againstOpen settings, but pressing it does nothing.- Clicking Press hotkey… and pressing
⌘+ the key labeled,does not register. - This remains true after removing
⌘+,fromOpen settings, so nothing in Obsidian holds the binding at that point and the recorder still cannot see it. ⌘+⌥+Sand⌘+;are both captured and work normally.
The native menu key equivalent is generated from the hotkey config
- Removing
⌘+,fromOpen settingsand leaving⌘+⌥+Sbound changes the displayed glyph to⌘⌥S. - With
⌘+,removed, pressing it produces no menu flash — nothing claims it. - Restoring the default restores both the
⌘ ,glyph and the flash-with-no-modal behaviour.
Behaviour under the Canadian QWERTY input source
Same hardware, so key labels no longer match the characters produced:
⌘+ key labeled;(physicalComma, producing,) — opens Settings correctly.⌘+ key labeled,(physicalKeyM, producingm) — minimizes the window, i.e. ordinary⌘+M.
The same logical shortcut works when the , character originates from physical Comma, and fails when it originates from physical KeyM.
Cross-application comparison
All tests: French input source, AZERTY Magic Keyboard, keys reported as labeled on the board.
| Application | Framework | ⌘ + key labeled , |
⌘ + key labeled ; |
|---|---|---|---|
| Claude Desktop | Electron | Opens settings | Nothing |
| Postman | Electron | Opens settings | Nothing |
| Google Chrome | Chromium | Opens settings | Nothing |
| Telegram | Native AppKit | Opens settings | Nothing |
| Obsidian | Electron | Menu flashes, no modal | Nothing |
| Docker Desktop | Electron | Fails | Nothing |
| Cursor | Electron | Fails | Nothing |
Two Electron applications and one native application handle the identical keystroke correctly under the identical layout, so this does not appear to be a platform or framework limitation.
Ruled out
- macOS App Shortcuts — no entries for Obsidian or All Applications. Adding one with the exact
Settings…menu title did not help. - Third-party global hotkey tools — none installed.
- Multiple or popped-out windows — single window, single vault.
- Stale state — full quit (
⌘+Q) and relaunch did not change anything. - Community plugins, themes and CSS snippets — reproduces in the sandbox vault.
- Apple’s automatic key-equivalent localization — every application tested displays a
⌘,glyph next to its Settings item under the French layout, so no application is receiving a localized key equivalent.
Impact
The default binding is unreachable and cannot be reassigned on this layout. Rebinding to ⌘+; works under the French layout but collides with the default under Canadian QWERTY, so users who switch layouts between an external and a built-in keyboard would have to re-edit hotkeys on every switch.
Possibly related
- Open settings shortcut (cmd+,) does not work —
112693(taggedtracked, French AZERTY) - Danish / Swedish / German Layout: both physical
⌘+<and⌘+,trigger the same command on macOS —57352