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

[mbeckenbach]

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. Ensure to use a German Mac Keyboard layout
2. Open a Terminal inside t3code desktop app on MacOS
3. Try to type the @ character

Expected behavior

I should be able to type the @ character in terminal by [option]+[l]

Actual behavior

Nothing happens. Terminal does not seam to receive the typed char.

Impact

Blocks work completely

Version or commit

0.0.43-nightly.20260921.2058

Environment

MacOS 27.0 (26A428)

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Not a workaround but additional info: The same issue is also typical for german keyboards in MacOS Terminal App. There you can fix it by unchecking "Use Option as Meta key" in the MacOS Terminal App settings. Possibly similar issue.

[juliusmarminge]

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.

[mbeckenbach]

@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 \

[jockee]

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.

[wouter-leistra]

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).