JetBrains Terminal: A New Architecture

We’re excited to announce our reworked terminal architecture, which is available in Beta starting with the 2025.1 versions of JetBrains IDEs. It now runs on a stable, standards-compliant core and uses the IDE’s editor for UI rendering. This change lets us introduce new features while preserving compatibility and performance across various platforms, whether local or […]

Apr 8, 2025 - 15:21

We’re excited to announce our reworked terminal architecture, which is available in Beta starting with the 2025.1 versions of JetBrains IDEs. It now runs on a stable, standards-compliant core and uses the IDE’s editor for UI rendering. This change lets us introduce new features while preserving compatibility and performance across various platforms, whether local or remote.

In this article, we’ll take a look at the evolution of terminal architecture in JetBrains IDEs and explain why we chose this approach as the foundation for developing new IDE features – and potentially even a standalone tool.

To enable it, navigate to Preferences|Settings/Tools/ Terminal and select Reworked 2025 from the Terminal engine dropdown menu. As we collect your feedback, we’ll gradually make it the default.

The classic terminal

For many years, JetBrains IDEs shipped with a built-in terminal based on the JediTerm library – a robust Java terminal emulator providing a time-tested, standards-compliant xterm/VT100 environment.

This classic approach delivered:

Full transparency: User input was forwarded directly to the shell (e.g. Bash, Zsh, or fish), ensuring that all standard command-line shortcuts, autocompletion frameworks, and plugins worked as intended.
Reliability: TUI programs such as Vim, tmux, and htop behaved as they would in an external terminal window.
Simplicity: Developers and DevOps engineers could count on the built-in terminal to behave like a regular console, respecting user muscle memory for key bindings like Ctrl+C and Ctrl+L.

The new terminal (2023–2024)

In 2023, we decided to experiment with a more “intelligent” approach. Instead of letting the shell handle line editing and shortcuts directly, the terminal intercepted user input (e.g. keystrokes and prompt text) inside the IDE and only sent commands to the shell when the user pressed Enter.

The plan was to:

Render the input locally with the IDE editor’s advanced UI capabilities.
Introduce block-structured command output for clarity.
Pave the way for future features such as AI or popup-based autocompletion at the IDE level.

Unfortunately, this radical shift led to major compatibility issues:

Conflicts with shell behavior: Shells like Bash, Zsh, and fish rely on receiving keystrokes as you type for built-in autocompletion, Ctrl+R history searches, and so on. By buffering input until Enter was pushed, we inadvertently disabled or broke these standard features.
Broken key bindings: Users reported that Ctrl+C no longer reliably stopped running processes, that Ctrl+L and the arrow keys behaved differently than expected, and that muscle-memory shortcuts from their custom .bashrc, .zshrc, or plugin-based setups (such as Oh My Zsh) no longer worked.
Disruption of TUI programs: Many terminal-based applications (Vim, less, tmux, etc.) expect standard terminal I/O sequences. The partial interception and rewriting of output frequently led to broken interactive interfaces or lost keystrokes.
Overstepping UI: Standard shell prompts, colorized themes, and advanced shell plugins sometimes simply did not appear because the new terminal tried to replace them with an IDE-based prompt. Users felt their carefully curated setups were being ignored or overridden.

User feedback on these issues arrived swiftly. Large numbers of EAP testers reverted to the classic terminal or used external terminals altogether, citing that the new design broke fundamental shell workflows. The volume of negative reports made it clear that an approach that deviates heavily from established POSIX-like terminal standards is unacceptable to most developers.

Reassessment: Why compatibility must come first

Our biggest takeaway was that compatibility and consistency are absolutely paramount when it comes to terminal behavior. The feedback highlighted that:

Muscle memory is critical. Standard keybindings (Ctrl+C, Ctrl+L, arrow keys, Ctrl+R, etc.) must work exactly as expected.
Native shell environments (Oh My Zsh, fish, custom aliases, themes like Powerlevel10k, and extensions like Starship, etc.) must be fully loaded and not replaced by a partial IDE reimplementation.
Performance and responsiveness cannot regress. Typing input and running commands should be as fast as or faster than in a standalone terminal.
Integration with TUI apps (Vim, tmux, htop) must remain unbroken. Full POSIX and xterm/VT100 compliance are essential.

From this feedback, we concluded that the terminal must remain a transparent pipeline for both user input and shell processes. Any new capabilities – like inline AI suggestions or a block-based UI – should only be added on top, without undermining any traditional terminal behavior.

The reworked terminal (2025)

“If I have seen further, it is by standing on the shoulders of giants.”
—Isaac Newton

After carefully analyzing the user feedback and the drawbacks of the new terminal, we have returned to a conservative baseline:

JediTerm as the core emulator: We have preserved the same low-level xterm/VT100 engine, which connects directly to a PTY. Commands, signals, and keystrokes are passed through to the user’s chosen shell, ensuring maximum compatibility and consistency. All shell features, shortcuts, and plugins work precisely as they do in a standard external terminal.
Rendering via the IDE editor: We’ve integrated the terminal display into the IntelliJ Platform’s editor component (with GPU acceleration), enabling advanced text rendering and potential UI enhancements (such as the block-based visual grouping of commands and outputs). Critically, these enhancements do not disrupt the shell’s logic or break standard CLI behavior.
Remote development workflows are being supported as the primary modes of operation, and active development in this area is ongoing.

We’re focusing on compatibility and performance before features:

Shell shortcuts, signals, rendering, and TUI applications must all behave exactly like they do in a normal terminal.
The terminal should exhibit typing responsiveness, the ability to handle large output volumes, and minimal CPU/memory overhead.
Block-structured output, deep AI integration, the ability to search in command history blocks, and other new functionality will be introduced gradually and optionally, keeping classic terminal workflows intact.

Plans

Looking ahead, we plan to layer in new features without sacrificing speed or consistency:

Advanced AI integration (with both local and cloud-based models and agents) to help you with routine tasks, advanced Dev and Ops scripts, and infrastructure-related command templates, all while still honoring the shell’s native capabilities.
Full-screen mode to allow you to focus more intently on the terminal.
Session restore across IDE restarts.
Security and cloud enhancements, as well as possible plugin APIs for advanced customization.
Potentially, a standalone release for OS-level usage.

The evolution of the JetBrains IDE terminal demonstrates how innovation must never undermine core compatibility. Our experiment with custom input handling in the new terminal revealed the depth of reliance users have on classic CLI behaviors, prompting a swift realignment to a fully POSIX-compliant approach.

Your voice matters!

Now is the perfect time to share in the comments what matters most to you and what we should take into account for the terminal. We will carefully consider every piece of feedback to build the most user-friendly terminal together.

Top: the classic terminal, Center: the new terminal (2023–2024), Bottom: the reworked terminal (2025)