⌘+, does not open Settings on a French AZERTY layout (macOS)

Steps to reproduce

  1. Use a keyboard where the , key sits at the physical US KeyM position — a French AZERTY board. (Reproducible on any keyboard by setting the input source to French, then pressing the physical M key.)
  2. Set the macOS input source to French.
  3. 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 → Hotkeys lists ⌘ , against Open settings, but pressing it does nothing.
  • Clicking Press hotkey… and pressing + the key labeled , does not register.
  • This remains true after removing ⌘+, from Open settings, so nothing in Obsidian holds the binding at that point and the recorder still cannot see it.
  • ⌘+⌥+S and ⌘+; are both captured and work normally.

The native menu key equivalent is generated from the hotkey config

  • Removing ⌘+, from Open settings and leaving ⌘+⌥+S bound 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 ; (physical Comma, producing ,) — opens Settings correctly.
  • + key labeled , (physical KeyM, producing m) — 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 (tagged tracked, French AZERTY)
  • Danish / Swedish / German Layout: both physical ⌘+< and ⌘+, trigger the same command on macOS — 57352

probably this

The APIs for capturing hotkeys did not offer the level of control we needed when we tried. After several iterations, We settled to the current solution which offends the least amount of people.