Toastty

A Ghostty fork that adds a Discord-style channel sidebar for long-lived, background-persistent terminal sessions.
About · Relationship to Ghostty · Building · Contributing

About

Toastty is a fork of Ghostty that replaces the macOS app's native tab system with a Discord-inspired sidebar of "channels". Each channel owns a long-lived Ghostty surface (terminal instance); switching channels swaps which one is visible but does not destroy the backgrounded surfaces, so their shells and any commands they are running keep executing between switches. Think of each channel like a tmux session you can click to — the PTY never dies, the I/O thread never pauses, the scrollback is intact when you come back.

The goal is to treat a single Toastty window as a lightweight workspace manager for terminal-based work: long-running dev servers in one channel, log tailing in another, an ad-hoc scratch shell in a third, all alive at once without the "which terminal window was that again?" shuffle.

Phase 1 (the current state) ships the sidebar, a hardcoded set of starter channels, background persistence across channel switches, splits within a channel, and exit/close_surface closing only the active channel rather than the whole window. See ROADMAP.md for the phase-by-phase direction and macos/Sources/Toastty/ for the implementation.

Relationship to Ghostty

Toastty is a thin fork, not a reimplementation. The entire Zig core (VT parser, PTY handling, Metal renderer, font engine, config system, theme loading) is Ghostty, unchanged. Everything under src/, pkg/, include/, and most of macos/Sources/ is upstream Ghostty code, and the fork pulls upstream changes regularly. Toastty-specific code is isolated to macos/Sources/Toastty/ plus a small number of targeted hooks in macos/Sources/Features/Terminal/ and macos/Sources/App/macOS/AppDelegate.swift — see the "Known exceptions" list in CLAUDE.md for the current set.

Because the core is unchanged:

• Toastty reads the same ~/.config/ghostty/config as Ghostty. Your existing config, keybinds, themes, and shell integration all work.
• The ghostty CLI command (ghostty +list-themes, ghostty +help, etc.) is available inside a Toastty terminal the same way it is inside a Ghostty one.
• Bundle identifier is still com.mitchellh.ghostty (and com.mitchellh.ghostty.debug for debug builds) so AppleScript, Launch Services, and config paths stay compatible.
• The Swift source code still uses Ghostty.App, Ghostty.Surface, GhosttyKit, etc. — only the display name, menu labels, and About dialog are rebranded to Toastty. This is deliberate: it keeps upstream merges conflict-free.

All credit for the terminal itself goes to the Ghostty project and its contributors. Toastty is licensed under the same MIT license as Ghostty (see LICENSE).

Building

Toastty is macOS-only in practice. See AGENTS.md → "Build" for the full instructions, but in short:

# First time: install the Metal Toolchain if your Xcode does not
# ship with it yet.
xcodebuild -downloadComponent MetalToolchain

# Rebuild the underlying Ghostty library (GhosttyKit.xcframework). Run
# this whenever you edit anything outside macos/ — the Zig core under
# src/, the C headers under include/, the Zig build system under pkg/,
# and so on — so the next macos/build.nu picks up the fresh library.
# Pure Swift edits under macos/Sources/ do NOT require this step.
zig build -Demit-macos-app=false

# Build the macOS app.
macos/build.nu --configuration Debug --action build

# Launch.
open macos/build/Debug/Toastty.app

Prerequisites: Xcode 26 with the macOS 26 SDK, Zig 0.15.2+, Nushell (brew install nushell).

Status

Toastty is a personal fork and is not (currently) intended for general distribution — treat it as a work-in-progress research branch. See ROADMAP.md for the phase-by-phase direction and GitHub Issues for concrete, actionable work. Anything about Ghostty's terminal core (VT handling, renderer, config, etc.) should go upstream instead.

Ghostty's original README

The original Ghostty project README — covering its roadmap, competitive performance, the libghostty embedding story, crash reports, and the Sentry integration details — is preserved below for reference.

---

Click to expand the original Ghostty README

About Ghostty

Ghostty is a terminal emulator that differentiates itself by being fast, feature-rich, and native. While there are many excellent terminal emulators available, they all force you to choose between speed, features, or native UIs. Ghostty provides all three.

libghostty is a cross-platform, zero-dependency C and Zig library for building terminal emulators or utilizing terminal functionality (such as style parsing). Anyone can use libghostty to build a terminal emulator or embed a terminal into their own applications. See Ghostling for a minimal complete project example or the examples directory for smaller examples of using libghostty in C and Zig.

For more details, see About Ghostty.

Download

See the download page on the Ghostty website.

Documentation

See the documentation on the Ghostty website.

Contributing and Developing

If you have any ideas, issues, etc. regarding Ghostty, or would like to contribute to Ghostty through pull requests, please check out our "Contributing to Ghostty" document. Those who would like to get involved with Ghostty's development as well should also read the "Developing Ghostty" document for more technical details.

Crash Reports

Ghostty has a built-in crash reporter that will generate and save crash reports to disk. The crash reports are saved to the $XDG_STATE_HOME/ghostty/crash directory. If $XDG_STATE_HOME is not set, the default is ~/.local/state. Crash reports are not automatically sent anywhere off your machine.

Crash reports are only generated the next time Ghostty is started after a crash. If Ghostty crashes and you want to generate a crash report, you must restart Ghostty at least once. You should see a message in the log that a crash report was generated.

[!NOTE]

Use the ghostty +crash-report CLI command to get a list of available crash reports. A future version of Ghostty will make the contents of the crash reports more easily viewable through the CLI and GUI.

Crash reports end in the .ghosttycrash extension. The crash reports are in Sentry envelope format. You can upload these to your own Sentry account to view their contents, but the format is also publicly documented so any other available tools can also be used. The ghostty +crash-report CLI command can be used to list any crash reports. A future version of Ghostty will show you the contents of the crash report directly in the terminal.

To send the crash report to the Ghostty project, you can use the following CLI command using the Sentry CLI:

SENTRY_DSN=https://e914ee84fd895c4fe324afa3e53dac76@o4507352570920960.ingest.us.sentry.io/4507850923638784 sentry-cli send-envelope --raw <path to ghostty crash>

[!WARNING]

The crash report can contain sensitive information. The report doesn't purposely contain sensitive information, but it does contain the full stack memory of each thread at the time of the crash. This information is used to rebuild the stack trace but can also contain sensitive data depending on when the crash occurred.