Summary
Fork Ghostty to add native wrightty protocol support, similar to the Alacritty fork.
Why fork instead of bridge
Ghostty's AppleScript API (macOS only) can send input and manage sessions, but cannot read screen content — the terminal buffer is not exposed. On Linux there is no control IPC at all. A bridge cannot implement Screen.getText or any read operations, which are core to wrightty.
A native fork embeds the wrightty protocol directly into the emulator, reading from the internal terminal state with zero overhead — the same approach that works for Alacritty.
What native support provides
Full wrightty protocol support:
- All Screen methods (getText, getContents, getScrollback, screenshot, waitForText, waitForCursor)
- All Input methods (sendKeys, sendText, sendMouse)
- All Session methods (using Ghostty's native tab/split model)
- All Terminal methods (resize, getSize, setColorPalette, getModes)
- All Events (screen updates, shell integration, title changes, etc.)
- Video recording (Tier 2) — Ghostty uses GPU rendering, same approach as Alacritty fork
Implementation approach
- Fork Ghostty
- Add a WebSocket server (port 9420) behind a
--wrightty flag
- Wire JSON-RPC handlers to Ghostty's internal terminal state (
TerminalStream, Screen, Surface)
- Expose the same protocol as the Alacritty fork
Ghostty internals (relevant)
- Written in Zig + C (libghostty core) with platform-native frontends (GTK on Linux, AppKit on macOS)
- Terminal state managed by
terminal.Screen and terminal.Terminal
- GPU rendering via Metal (macOS) / OpenGL (Linux) — enables Tier 2 video recording
- Has a concept of "surfaces" (terminal instances) that map to wrightty sessions
Challenges
- Zig codebase (vs Rust for Alacritty fork) — different toolchain
- Ghostty is not yet fully open-source for contributions (source-available license)
- Platform-specific frontends may require separate integration points
References
Summary
Fork Ghostty to add native wrightty protocol support, similar to the Alacritty fork.
Why fork instead of bridge
Ghostty's AppleScript API (macOS only) can send input and manage sessions, but cannot read screen content — the terminal buffer is not exposed. On Linux there is no control IPC at all. A bridge cannot implement
Screen.getTextor any read operations, which are core to wrightty.A native fork embeds the wrightty protocol directly into the emulator, reading from the internal terminal state with zero overhead — the same approach that works for Alacritty.
What native support provides
Full wrightty protocol support:
Implementation approach
--wrighttyflagTerminalStream,Screen,Surface)Ghostty internals (relevant)
terminal.Screenandterminal.TerminalChallenges
References