# Ghostty adds image clipboard support; stable release users still wait > Source: > Published: 2026-08-25 01:56:11+00:00 # Ghostty adds image clipboard support; stable release users still wait **Ghostty and libghostty now implement OSC 5522, letting terminal tools move images and other MIME data across supported sessions.** By [RuntimeWire Staff](/author/runtimewire-staff) ยท Published Primary source: [Mitchell Hashimoto on X](https://x.com/mitchellh/status/2092001755055972800) ## Why it matters Image-aware clipboard support gives remote editors and coding agents a standard path to local screenshots, while making libghostty more useful as shared terminal infrastructure. [Mitchell Hashimoto (@mitchellh)](https://x.com/mitchellh/status/2092001755055972800?ref=runtimewire) said on August 24th that Ghostty and its reusable terminal engine, libghostty, now implement Kitty's clipboard protocol for non-text data, including images. The work is in Ghostty's development tree. It has not reached a tagged stable release. That distinction sets the scope of the announcement. Hashimoto and other contributors have built the protocol machinery needed to move MIME-typed data through terminal sessions. A Ghostty 1.3.1 user cannot assume image transfer is available today, and support at the terminal layer does not automatically make every editor, multiplexer or coding agent compatible. Hashimoto, who co-founded HashiCorp after meeting Armon Dadgar at the University of Washington, began Ghostty as a personal side project. Its architecture separates platform-native desktop interfaces from a shared Zig core. The macOS and Linux applications both consume [libghostty](https://ghostty.org/docs/about?ref=runtimewire), which Hashimoto wants other developers to use for their own terminals, editors and embedded command-line interfaces. The clipboard work lands directly in that shared core, making it relevant beyond Ghostty's own desktop application. ### The clipboard stops being text-only The older OSC 52 terminal sequence can read and write plain text. Kitty's [OSC 5522 specification](https://sw.kovidgoyal.net/kitty/clipboard/?ref=runtimewire) adds MIME types, allowing an application to request or send formats such as `image/png` alongside text and richer document data. The protocol also defines permission prompts, error responses and multipart transfers. Data is base64-encoded and divided into decoded chunks of no more than 4,096 bytes. Those details are necessary when the clipboard contains an image that is far larger than an ordinary line of text. Ghostty's first substantial [implementation commit](https://tangled.org/jcollie.dev/ghostty/commit/819b241dec1a3a6a4c1c87f0b01152c99197c02a?ref=runtimewire), dated August 21st, added the core request parser, response encoder, MIME handling, permission grants and state for multipart writes. The commit explicitly said the application-runtime hooks were not connected yet, so its code was not functioning in the real binary at that stage. A subsequent [August 22nd commit](https://tangled.org/jcollie.dev/ghostty/commit/4f49dc2b8bfcd8b1a33de8a95d3b1a1a7135496f?ref=runtimewire) connected OSC 5522 reads to libghostty's clipboard callback. Further development-tree work added the corresponding read and write paths. Hashimoto's announcement reflects that progression from protocol parsing to an implementation embedders can use. The immediate use case is moving screenshots and other structured clipboard data into terminal applications. Developers have been asking for that capability in workflows involving remote editors and AI coding tools, where the program runs over SSH and cannot directly inspect the clipboard on the user's local machine. Ghostty contributors discussed that limitation in an [image clipboard request](https://github.com/ghostty-org/ghostty/discussions/10099?ref=runtimewire) and a [remote image proposal](https://github.com/ghostty-org/ghostty/discussions/10517?ref=runtimewire). OSC 5522 provides a common protocol for that exchange, although the application and any terminal multiplexer between the application and Ghostty must also handle it correctly. Ghostty implementing one end of the connection does not complete the full toolchain. ### Hashimoto keeps building below the interface The feature follows the pattern Hashimoto has established since leaving HashiCorp in 2023: build the difficult systems layer, then make it available to other developers. Ghostty's desktop application is one consumer of libghostty rather than the library's endpoint. Hashimoto has positioned reusable building blocks as public infrastructure for other developers. He [claims Ghostty and libghostty reach millions of daily users](https://mitchellh.com/writing/superlogical?ref=runtimewire), although he has not published a measurement methodology for that combined figure. RuntimeWire [reported in July that Hashimoto started Superlogical](/article/mitchell-hashimoto-superlogical-terminal-multiplexer) with former HashiCorp colleagues to build durable software sessions around a terminal multiplexer. Ghostty follows a separate path: Hashimoto donated its intellectual property to a federally recognized nonprofit in 2025 and has said he does not intend to commercialize it. [Ghostty's sponsorship documentation](https://ghostty.org/docs/sponsor?ref=runtimewire) says donations support open-source development and paid contributor contracts, while Hashimoto remains project lead. That structure changes the incentive behind protocol work such as OSC 5522. Ghostty does not need to reserve the capability for a paid tier or use it to push users into a proprietary workflow. Wider adoption of libghostty advances the project's stated purpose. Hashimoto made that invitation explicit in a follow-up to the announcement. Responding to a question about Windows, he said libghostty works there and added, "Someone should build a GUI." Ghostty itself still provides official desktop applications for macOS and Linux, but the comment captures the library strategy: Hashimoto wants other developers to own the interface while libghostty handles terminal internals. ### A development feature, not a stable release Ghostty's [published release index](https://ghostty.org/docs/install/release-notes?ref=runtimewire) still lists version 1.3.1, released on March 13th, as the newest stable build. Its release notes predate the OSC 5522 implementation. Ghostty has not identified the first stable version that will contain the feature. Libghostty also lacks a standalone, versioned stable API. Ghostty's 1.3 release notes described the Zig module as available and the C API as a work in progress, with separate release cycles planned for the library and desktop application. Developers embedding the current code are therefore building against a moving interface. The implementation still gives terminal-tool authors a concrete target. Kitty defined the protocol, and Ghostty has now adopted it in a second major terminal codebase with an embeddable core. Broader interoperability will depend on editors, multiplexers and coding agents implementing the same exchange. For Hashimoto, that is the larger bet behind a seemingly narrow clipboard patch. Images moving through terminal sessions make Ghostty more capable. The same implementation inside libghostty gives other developers a shared piece of infrastructure they no longer have to write themselves.