[Bug]: Cannot type @ char in Terminal on MacOS with German Keyboard Layout #13046

Activity

1. mbeckenbach

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 22, 2026
2. juliusmarminge commented on Sep 22, 2026

   

   juliusmarminge

   on Sep 22, 2026

   Member

   More actions

   This is a real macOS terminal input bug, and it is not the Shift-@ issue from #5276 / #7485.

   On a German Mac layout, @ is Option+L. The desktop terminal (and the web app, which uses the same Ghostty surface) always forwards Option as Alt into libghostty-vt. The WASM encoder is not built as macOS, so Ghostty’s macos-option-as-alt = false path — the one that types the composed character — never runs. alt_esc_prefix (DEC 1036) is on by default, and ghosttyConsumedMods only consumes a lone Shift.

   Option+L is therefore sent as ESC @. At a bash/zsh prompt that is set-mark, so no character appears. The same encoding drops the other Option-layer ASCII keys used on this layout ([ ] { } | ~ \). Electron does not set AltGraph for Option, so the existing AltGr bypass in isTerminalAltGraphText does not apply. Option+arrow word motion is handled separately and is not what is eating this key.

   Fixing this means treating a lone Option that produced a printable character as composing input (mark Alt consumed, or write event.key directly), which is Terminal.app with “Use Option as Meta key” off. Note that Option+letter Meta chords such as Option+B currently become ESC b through the unshifted-codepoint fallback, so that behavior will change. Setting GHOSTTY_KEY_ENCODER_OPT_MACOS_OPTION_AS_ALT will not help: every key press resets it via setopt_from_terminal, and the WASM build ignores it anyway.
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 22, 2026
4. mbeckenbach commented on Sep 22, 2026

   

   mbeckenbach

   on Sep 22, 2026

   Author

   More actions

   @juliusmarminge Thanks for checking. I tested some more on my german keyboard here. the issue does not only affect the @ char. It affects also:

   • option+e for €
   • option+n for ~
   • option+number row for chars like []|{}'
   • option+shift+7 for \
5. jockee commented on Sep 24, 2026

   

   jockee

   on Sep 24, 2026

   More actions

   Same problem on a Swedish Mac layout, in the stable build 0.0.42 (T3 Code (Alpha), macOS). Every Option+number combination types nothing in the terminal, so I can't type | (⌥7), @ (⌥2), $ (⌥4), [ ] (⌥8/⌥9) or { } (⇧⌥8/⇧⌥9). Pasting with Cmd+V works.

   This looks like the terminal's keydown handler. From the bundled ThreadTerminalDrawer chunk:

   function Ft(e){return e.getModifierState(`AltGraph`)&&[...e.key].length===1}
   // ...
   onKeyDown=e=>{if(Ft(e)||!this.options.beforeKey(e)){this.suppressedKeyCodes.add(e.code);return} ...

   Only AltGr is allowed to fall through to text input. On macOS, Chromium reports Option as altKey, never AltGraph, so a composed character like e.key === "|" from ⌥7 doesn't go through the text-input path. It goes through encodeKey with the alt modifier set instead.

   A possible fix: on macOS, treat altKey && !ctrlKey && !metaKey && [...e.key].length === 1 the same as AltGraph and send e.key as text. Ghostty's macos-option-as-alt setting could make this opt-out for people who want Option to act as Alt.
6. wouter-leistra commented on Sep 25, 2026

   

   wouter-leistra

   on Sep 25, 2026

   Last edited by wouter-leistra

   More actions

   Finnish layout here on my M5.

   My claude came to the following conclusion:

   Your keyboard is fine. This is a bug in T3 Code's terminal.

   Cause. T3's terminal (a libghostty-vt build compiled to WebAssembly) treats Option as Alt whenever you press it. It ignores the character macOS already produced. I loaded the app's own ghostty-vt-DdA0Zryv.wasm in Node and fed it an Option+7 keypress with the character |:

   Terminal state	Bytes sent to the shell
   Default	`ESC
   After fish turns on the kitty keyboard protocol	ESC[55;3u (Alt+7)

   In both cases fish gets an Alt shortcut that has nothing bound to it, so nothing appears. T3 has a check for this, but it only covers the AltGraph key on Windows and Linux. On a Mac, Option never counts as AltGraph, so the check never kicks in. There's no T3 setting to change this. The real fix is upstream: T3 should treat Option as used up when it produced a character. That's worth filing with T3 (pingdotgg/t3code).