JetBrains IDEs Fully Integrate the libghostty Terminal Engine

An Under-the-Hood Overhaul of the Terminal Experience

JetBrains has announced that its IDE product line is now powered by libghostty for terminal support. This change means that when developers use tools like IntelliJ IDEA, PyCharm, and WebStorm, the built-in terminal will run on Ghostty's rendering core rather than the previous in-house or otherwise-based implementation.

libghostty is a reusable library extracted from the Ghostty terminal emulator. Ghostty, led by Mitchell Hashimoto, has gained attention for its native performance, GPU-accelerated rendering, and cross-platform consistency. By embedding it into its IDEs, JetBrains is essentially upgrading the terminal from an "attached panel" to a component with its own independent rendering pipeline.

Why libghostty

Traditional IDE built-in terminals are often based on Swing or JCEF wrappers, and tend to drop frames when handling high-throughput output, complex escape sequences, and wide-character rendering. The core capabilities libghostty provides include:

• A terminal state machine and parser independent of the UI framework
• A GPU-based rendering path that reduces CPU usage in high-frequency output scenarios
• Native support for modern terminal protocols (such as the Kitty graphics protocol and hyperlinks)
• Consistent character width and color handling across platforms

For JetBrains, adopting a mature library is more engineering-efficient than continuing to maintain a self-developed terminal core. According to discussion on Hacker News, the community's overall reaction to this decision has been positive, viewing the terminal experience as one of the long-criticized aspects of the JetBrains toolchain.

Ghostty is an open-source terminal emulator led by Mitchell Hashimoto (co-founder of HashiCorp), written in the Zig language, with the design goal of providing a native GUI experience on each platform while maintaining consistent terminal behavior. It uses platform-native UI toolkits (SwiftUI/AppKit on macOS, GTK on Linux) rather than Electron or web technology stacks, which gives it excellent startup speed and input latency. Another characteristic of Ghostty is its strict adherence to terminal standards and protocols, with relatively accurate handling of wide characters, combining characters, and true-color output. libghostty is the core library extracted from Ghostty, encapsulating the terminal state machine, parser, and rendering logic so that third-party applications can reuse its terminal capabilities without depending on Ghostty's GUI layer. This "core library + multiple frontends" architecture has been the direction planned for the Ghostty project from the start, and JetBrains' adoption is the first large-scale implementation of this design.

The Kitty graphics protocol is an extension protocol proposed by the Kitty terminal emulator that allows terminal applications to display images directly within the terminal window, rather than being limited to text and character art. Traditional terminals can only control a character grid through escape sequences, and displaying images usually requires older protocols like Sixel or external windows. The Kitty protocol supports multiple formats such as PNG and raw RGB data, and can specify the display position, size, and scaling of images. It is commonly used to preview images, render charts, or display icons in the terminal. For JetBrains IDE users, this means that when running image-processing scripts in the terminal, viewing test screenshots, or using TUI tools that support the protocol, images can be displayed inline directly. The hyperlink protocol allows the terminal to recognize and render clickable URLs, giving links in terminal output interactive capability. Both of these capabilities previously had limited support in IDE built-in terminals.

Practical Impact on Developers

In the short term, the changes will be reflected in terminal response speed and rendering accuracy. Users who frequently run build scripts, execute test suites, or use TUI tools (such as htop, tmux, and vim) will notice less flickering and lower input latency.

In the medium to long term, libghostty's modular design provides a foundation for JetBrains to open up terminal capabilities further. For example, the plugin ecosystem can reuse the same terminal parsing logic, reducing behavioral inconsistencies. However, whether terminal configuration options, keybindings, and theme inheritance methods are fully compatible with existing user habits still needs to be verified through actual use.

A Signal at the Ecosystem Level

JetBrains replacing a core component with an external open-source library reflects a growing tendency among IDE vendors to "assemble" rather than "rebuild" foundational capabilities. This contrasts with the editor space, where VS Code relies on xterm.js and Zed develops its own GPUI terminal. As a high-frequency interaction entry point, the terminal's rendering quality directly affects developers' day-to-day experience, and the introduction of libghostty is a clear reinforcement by JetBrains on this dimension.

xterm.js is a terminal frontend component written in TypeScript, originally developed for VS Code's built-in terminal and later becoming an independent open-source project. It runs in browsers or web views, rendering characters via Canvas or WebGL, and is used by many tools including VS Code, Hyper, and Tabby. It is the representative implementation of terminals on the web technology stack. In contrast, the GPUI terminal developed in-house by the Zed editor takes a native GPU rendering route, pursuing extreme input latency and frame rates. JetBrains' choice of libghostty sits between the two: neither a self-developed rendering engine nor a web wrapper, but rather the introduction of a native and modular third-party core. The differences among these three paths reflect divergent views among IDE vendors on the positioning of the terminal component—whether to treat it as pluggable infrastructure or as part of a differentiated experience.

Open Questions

Public information is currently limited; the original Hacker News post provides only a title and a small amount of discussion. The following questions do not yet have clear answers: how old terminal configurations will be migrated, whether the original terminal engine will be retained as a fallback option, and how libghostty's update cadence will align with the IDE release cycle. These details will determine whether this replacement is a smooth upgrade or brings new adaptation costs.

For JetBrains users who rely heavily on the built-in terminal, it is recommended to focus on verifying scenarios such as multiplexing, true-color output, and input method compatibility after upgrading.

One-line Summary

JetBrains' full IDE lineup now uses the Ghostty-derived libghostty to drive its built-in terminal.

Paragraph Summary

JetBrains has announced that the built-in terminals across its IDE product line are now powered by libghostty, a reusable library extracted from the Ghostty terminal emulator. Ghostty is known for native performance, GPU-accelerated rendering, and cross-platform consistency, while libghostty encapsulates an independent terminal state machine, parser, and rendering path. Compared with the previous Swing- or JCEF-based implementation, the new terminal is expected to reduce frame drops and latency in high-throughput output, complex escape sequences, and wide-character rendering scenarios, and natively supports modern terminal capabilities such as the Kitty graphics protocol and hyperlinks. Community reaction has been generally positive, as the terminal experience has long been seen as a weak point in the JetBrains toolchain. However, details such as configuration migration, fallback options, and release cadence alignment have not been made public, and actual compatibility still needs verification.