# Extraterm: a terminal emulator that frames command output

> Extraterm is an MIT-licensed terminal emulator written in TypeScript, now built on Qt rather than Electron. Its shell integration can isolate the output of a single command, and that one design choice changes how you copy, reuse and search terminal text.

**sedwards2009/extraterm** — The swiss army chainsaw of terminal emulators

- Repository: https://github.com/sedwards2009/extraterm
- Website: https://extraterm.org
- Stars: 2,826 · Forks: 129
- Language: TypeScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/sedwards2009-extraterm

## What Extraterm is trying to fix about terminal text

A conventional terminal emulator is a stream of characters. Once a command finishes, its output is just more text in the scrollback, indistinguishable from the prompt above it or the command below it. Selecting the right lines is manual work. Reusing the output of one command as the argument to another means piping it through a file or a subshell.

Extraterm's answer is shell integration. The README describes it as the ability to "isolate and 'frame' command output", and lists bash, zsh and fish as the supported shells. A framed block is a unit: the emulator knows where one command's output begins and ends. That is the feature the rest of the emulator is organised around. Easy uploads and downloads also run through the shell integration, and previous command output can be used as input for new commands.

The audience is narrow and specific. This is for people who already live in a shell and find the terminal's text model the limiting factor, not the font rendering. It is not aimed at users who want a drop-in replacement with identical behaviour; the framing behaviour is a departure from what a terminal normally does.

## Qt, nodegui and the command palette architecture

The repository is a Yarn workspace monorepo. The top level holds `main`, `packages/`, `extensions/`, `build_scripts/`, `tools/` and `test/`, with `package.json` at the root declaring the workspaces. The root package is `private: true`, so this is a build tree rather than something you install from npm.

The runtime is not Node. The `run` script is `qode main/dist/main.cjs`, and `qode` is the Node-compatible runtime that comes with nodegui. The README distinguishes the "Modern Qt based version" (0.60.0 and later) from the "Classic Electron based version" (before 0.60.0), which it calls "pretty old". The `resolutions` block pins `@nodegui/nodegui` to 0.74.0 and TypeScript to 5.2.2, so the Qt binding is a fixed dependency rather than a floating one.

Build orchestration is `wsrun` across the workspace stages: `build`, `clean`, `lint`, `lint-strict` and `test` each fan out to every package. There is a separate `package` script that calls `jam-pack-nodegui` with a config at `build_scripts/extraterm-jam-pack.json`. Extensions live under `extensions/`, and the README points to a separate page on developing extensions. The practical consequence of this layout is that a source build is a multi-stage workspace build, not a single compile step.

## Installing Extraterm and framing your first command

The README does not give command-line install instructions. It points to the releases page for downloads, and states that Linux, Windows and OS X are supported. The modern Qt build is version 0.60.0 and later; the classic Electron build is the v0.59.4 release tag. The README notes that both can be installed at the same time without problems. Nightly builds of the `master` branch are linked from a separate downloads page.

So the first step is to download a release for your platform rather than to run an installer command. Once it is running, the shell integration is what you want to confirm. The supported shells are bash, zsh and fish.

```bash
# In an Extraterm tab running bash, zsh or fish:
# run any command that produces output, then look for the
# framed block boundary around its output in the scrollback.
ls -la
```

What you should see is the listing treated as one block rather than as loose lines, which is the precondition for the features built on top of it. From there, the README's own list of entry points is the guide page sections on colorizing, splits and panes, keybindings and inserting emoji, plus the Command Palette, which the README describes as keyboard friendly.

If you want to build from source instead, the root scripts are the entry point. The build fans out across workspaces, and the run step needs `qode` on your path:

```bash
yarn install
yarn build
yarn run
```

The `run` script sets `QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor` before launching `qode main/dist/main.cjs`, which is worth knowing if you launch the built output yourself and see different scaling behaviour.

## Where the framing model and the platform support stop

Shell integration is the load-bearing feature, and it is scoped to three shells: bash, zsh and fish. If your daily shell is not one of those, the framing, the upload and download helpers, and the reuse of previous output as input are not available to you. What remains is a terminal emulator with images, a mini-map, ligatures, 24-bit color and search, which is a reasonable terminal but not the reason the project exists.

Platform support is stated as Linux, macOS, and on Windows WSL, CMD and PowerShell. The README does not describe a native Windows build outside those shells, and it does not document a server mode, a daemon, or a way to attach to an existing session from a second machine. The built-in SSH client is listed as a feature, but the README does not document session persistence or reconnection semantics, so anyone whose workflow depends on surviving a dropped connection should treat that as unverified rather than assume it.

The Qt migration is another boundary. The README keeps the Electron version available and says it is "pretty old", which means bug reports and fixes are aimed at the Qt line. Running the classic build to get behaviour the Qt build does not have is possible, but you are on a branch the project describes that way itself.

## Extraterm against a GPU-accelerated terminal like Hyper

The obvious comparison is with the Electron-based terminals, Hyper being the common reference point. Both are JavaScript and TypeScript projects that treat the terminal as an application platform rather than a fixed system utility. The difference in approach is what each one optimises.

Hyper's model is the web stack: HTML, CSS and JavaScript for the shell itself, with configuration and plugins written in the same language. The trade-off is that you inherit a browser engine's memory and rendering characteristics, and the terminal's text model stays conventional.

Extraterm moved away from that. The Qt and nodegui runtime replaced Electron for the modern line, and the feature work went into the shell protocol rather than into the UI layer: framing output, moving output between commands, and routing uploads and downloads through the shell. The cost is that shell integration has to be installed per shell and works only with bash, zsh and fish, whereas a plugin in an Electron terminal does not need the shell's cooperation. If you want to restyle your terminal with CSS, Extraterm is the wrong tool. If you want the terminal to understand the structure of your command output, that is the whole point here.

A GPU-accelerated terminal is a third position: rendering throughput as the headline, with a conventional text model. Extraterm does not claim that ground either.

## Maintenance, licensing and the cost of tracking releases

The repository is not archived. The last push was on 2026-06-05, and the most recent release listed is v0.82.0 from 2026-05-10. Before that, v0.81.4 was released on 2025-08-30 and v0.81.3 on 2025-07-02. The gap between 0.81.4 and 0.82.0 is roughly eight months, so the release cadence is not fast, and the version numbering suggests incremental work rather than a stabilisation push.

For upgrade cost, the pinned dependencies matter more than the release notes. `@nodegui/nodegui` is held at 0.74.0 and TypeScript at 5.2.2 in the `resolutions` block, which means the Qt binding is a deliberate, fixed target. A source build therefore reproduces a known combination rather than tracking the latest of everything, and moving that pin is a project-level decision rather than something you do casually in your own checkout.

The licence is MIT, declared both in `LICENSE.txt` and in the `license` field of `package.json`. That is permissive and imposes no copyleft obligation on your own code. It says nothing about the licences of the Qt libraries the application links against at runtime, and the README does not discuss that, so if you are redistributing a build rather than using one, that is a question for your own review rather than something this repository answers.

## Conclusion

Adopt Extraterm if you spend the day in bash, zsh or fish and want command output treated as a block you can copy, search or feed into the next command, and if you are willing to install a Qt-based desktop application rather than a package your distribution already ships. Do not adopt it if you need a terminal that is already in your distribution's repositories, if you rely on a shell other than bash, zsh or fish, or if you need the terminal to stay inside a multiplexer session you attach to from several machines. Before committing, verify that a release build runs on your platform, that shell integration activates in your shell, and that the output framing behaves the way you expect on a command that produces a lot of text.

## FAQ

### What is Extraterm?

Extraterm is an open source terminal emulator written in TypeScript and licensed under MIT. The README describes it as a project to expand the terminal with new features rather than act as a glorified teletype, and lists shell integration, a built-in SSH client, images in the terminal and a command palette among its features.

### Where do I download Extraterm?

The README points to the GitHub releases page for downloads. The modern Qt-based version covers 0.60.0 and later, the classic Electron-based version is the v0.59.4 tag, and nightly builds of the master branch are linked from a separate downloads page.

### Which shells does Extraterm's shell integration support?

The README lists bash, zsh and fish as the supported shells for shell integration. That integration is what enables output framing, easy uploads and downloads, and using previous command output as input for new commands.

### Which platforms does Extraterm run on?

The README states support for Linux and macOS, and on Windows for WSL, CMD and PowerShell. The releases page describes Linux, Windows and OS X as supported.

## Sources

- [License: MIT](https://github.com/sedwards2009/extraterm/blob/master/LICENSE)
- [Project website](https://extraterm.org)
- [README](https://github.com/sedwards2009/extraterm/blob/master/README.md)
- [Releases](https://github.com/sedwards2009/extraterm/releases)
- [sedwards2009/extraterm on GitHub](https://github.com/sedwards2009/extraterm)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sedwards2009-extraterm