Unicode Hex Input produces �� instead of emoji on macOS

[richardgill]

Issue Description

I use macOS's Unicode Hex Input source to enter characters by typing their Unicode value while holding Option.

Characters represented by a single UTF-16 value work correctly. For example, holding Option, typing 2705, and releasing Option produces ✅.

Characters represented by two UTF-16 values do not work correctly. Holding Option, typing D83EDDF5, and releasing Option produces �� instead of 🧵. The same input produces 🧵 correctly in other macOS applications.

Keyboard: built-in MacBook Air keyboard
Input source: macOS Unicode Hex Input

Instructions for enabling Unicode Hex Input on MacOS:
https://servicedesk.uwgb.edu/TDClient/33/Portal/KB/Article/3648/Mac-Unicode-Hex-Input

This appears to be a remaining surrogate-pair edge case from the broader Unicode Hex Input problem discussed in #5306.

I have tested a proposed fix on my Mac:
https://github.com/richardgill/ghostty/tree/fix/macos-split-surrogate-input

AI disclosure: I used the Pi coding agent to help investigate the behavior, develop and test the proposed fix, and edit this report. I reviewed the final text and code.

Expected Behavior

Holding Option, typing D83EDDF5, and releasing Option should insert 🧵 once, matching the behavior of other macOS applications.

Actual Behavior

Ghostty inserts two Unicode replacement characters, ��, instead of 🧵.

Reproduction Steps

1. Enable the macOS Unicode Hex Input source by following these instructions:
   https://servicedesk.uwgb.edu/TDClient/33/Portal/KB/Article/3648/Mac-Unicode-Hex-Input
2. Use the minimal Ghostty configuration provided below.
3. Restart Ghostty and select Unicode Hex Input from the macOS input menu.
4. Hold Option, type 2705, and release Option. Ghostty inserts ✅ correctly.
5. Hold Option, type D83EDDF5, and release Option.
6. Observe that Ghostty inserts �� instead of 🧵.
7. Repeat the second input in another macOS application and observe that it inserts 🧵 correctly.

Feel free to tag me anytime if you would like me to test a fix on my machine.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Tahoe 26.5.1

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

macos-option-as-alt = false

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[bo2themax]

Can you even input them correctly in the spotlight? I couldn't

[bo2themax]

But the text field in the browser does work.

[00-kat]

I'm not on macOS so this is just a guess, but does 1F9F5 (🧵's code point, rather than UTF-16 encoding) work?

[bo2themax]

it doesn't seem to

[bo2themax]

#13733

[bo2themax]

Your suggested changes look good 👍 , but i have some suggestions in mind, will follow up later. Thanks for the feedback