[Bug]: Change appearance shortcut fails on macOS AZERTY (Option+Shift+Cmd+A)

[nbros]

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. Use a MacBook Pro with a French AZERTY keyboard layout.
2. Open T3 Code and keep focus outside the integrated terminal.
3. Open the command palette and search for "Change appearance". It advertises Option+Shift+Cmd+A (⌥⇧⌘A).
4. Close the palette and press that combination using the key labeled A on the AZERTY keyboard.
5. Press it several times to distinguish a missed shortcut from a transition between System and the same effective light/dark mode.

Expected behavior

The advertised shortcut should cycle System → Light → Dark → System, using the A key from the active keyboard layout.

Actual behavior

The advertised shortcut does not appear to change the appearance on my MacBook Pro with an AZERTY keyboard.

Suspected cause (source inspection)

In apps/web/src/keybindings.ts, resolveEventKeys falls back to the letter in KeyboardEvent.code when event.key is not a Latin a–z character. Option can turn a letter into a symbol. On AZERTY, the key labeled A has code KeyQ, so this fallback can resolve it as q rather than a and miss the default mod+alt+shift+a binding.

For example, a synthetic event with key: "Æ", code: "KeyQ", metaKey: true, altKey: true and shiftKey: true exercises this mismatch. This is a unit-test input, not a captured keyboard-event log from my machine.

Related reports

• [Bug]: macOS option-modified explicit keybindings with letter keys fail at runtime #2261: Option-modified letter shortcuts failing on macOS (closed).
• [Bug]: Keyboard shortcuts react to both physical and layout-derived keys #4434 / Limit physical key fallback to non-Latin layout output #4469: Latin layout letters take precedence over physical positions, but the physical fallback remains for Option-generated symbols.
• [Bug]: Keybindings Editor does not respect users keyboard layout #13229: the recorder displays US key positions for non-US punctuation (open); related layout handling, but a different symptom.

I did not find an existing report specifically covering Option-modified A on AZERTY for appearance.cycle.

Impact

Minor bug or occasional failure

Version or commit

Personal build based on upstream v0.0.45; shortcut matching inspected in the upstream source as well.

Environment

macOS, MacBook Pro, French AZERTY keyboard. macOS 26.7.1

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Use the command palette → Change appearance and select a mode manually, or assign a shortcut without Option in Settings → Keybindings.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @nbros for the careful report, and for working out which input would trigger it. Current main matches what you describe: on a French AZERTY layout, shortcut matching reads that key as q.

What I found

• The default binding for appearance.cycle is mod+alt+shift+a (packages/shared/src/keybindings.ts), and it runs from the command palette's keydown listener.
• resolveEventKeys in apps/web/src/keybindings.ts uses a Latin event.key as is. When Option turns the key into a symbol, it falls back to the US letter from event.code. On AZERTY, the key labeled A is KeyQ and Option+Shift+A produces Æ, so the event resolves to æ and q and never matches a.
• Change theme (mod+alt+a) misses for the same reason. Option shortcuts on letters that sit in the same place as on QWERTY (B, N, T) still match. On AZERTY the affected letters are A, Q, Z, and W.
• Limit physical key fallback to non-Latin layout output #4469 kept this physical fallback for Option-generated symbols when it stopped double-matching unmodified Latin letters. The issue here is separate from [Bug]: macOS option-modified explicit keybindings with letter keys fail at runtime #2261, [Bug]: Keyboard shortcuts react to both physical and layout-derived keys #4434, and [Bug]: Keybindings Editor does not respect users keyboard layout #13229.

Likely fix area

One option is to keep the #4469 rule for unmodified Latin letters and resolve an Option-generated symbol to the letter the active layout prints on that key, rather than the US letter in event.code. Until then, your workarounds are good: use the command palette, or bind the command without Option in Settings → Keybindings.

A maintainer will decide on the fix direction.