# microsoft/terminal ships the new terminal and the console host it replaced

> The repository behind Windows Terminal carries the app, the Preview channel, the conhost.exe it renders on top of, and the C++ samples for the Windows Console APIs. Five install routes, two Canary distributions, and two release lines that do not share a version number.

**microsoft/terminal** — The new Windows Terminal and the original Windows console host, all in the same place!

- Repository: https://github.com/microsoft/terminal
- Stars: 104,995 · Forks: 9,618
- Language: C++
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-terminal

## The repo ships the terminal and the console host it sits on top of

microsoft/terminal carries more than the app people install. Its own description calls it "The new Windows Terminal and the original Windows console host, all in the same place!", and the contents back that up: Windows Terminal, Windows Terminal Preview, the console host binary conhost.exe, the components shared between the two projects, a color tool at src/tools/ColorTool, and sample projects under samples/ that show how to consume the Windows Console APIs. The primary language is C++ and the licence is MIT, with main as the default branch.

The distinction matters when you are deciding what a download actually contains. conhost.exe is the piece Windows has always used to draw a console window, and Terminal is the newer front end that renders over the same console infrastructure. Both binaries are built from this one tree, which is why a bug report against either can land in the same tracker.

The supporting work sits in other places. The README points at learn.microsoft.com/windows/terminal for the documentation, a MicrosoftDocs/terminal repository to contribute to those docs, a MicrosoftDocs/Console-Docs repository for the Console API reference, and a separate Cascadia-Code repository for the font the app uses.

## Windows 10 build 19041 is the floor under every install path

Every route to this app starts at the same gate. The stated requirement is Windows 10 2004, build 19041, or later. No path in the repository serves anything older, and none serves macOS or Linux, so a machine below that build number has no way in here at all. That includes the portable Canary ZIP, which carries the same 19041 floor as the packaged builds.

The floor also decides which channel you can use, not just whether you can install. The Canary App Installer is limited to Windows 11 for platform reasons, so a Windows 10 machine that comfortably clears 19041 still cannot reach the auto-updating Canary distribution. The consequence for a reader is that installing a Windows terminal is not one decision. It is three: which Windows build you are on, which channel's update behaviour you can accept, and which package manager on your machine is current enough to resolve the dependency.

## winget, Chocolatey and Scoop each hand you a different upgrade story

The Microsoft Store route is described as preferred, because it keeps you on the newest build through automatic upgrades. Three command-line routes sit beside it, and they are not equivalent to each other.

winget installs the package by id:

```powershell
winget install --id Microsoft.WindowsTerminal -e
```

That path has a version floor of its own. Dependency support needs WinGet 1.6.2631 or later, and installing stable release 1.18 or later requires an updated WinGet client. A reader on an older client does not get a clear Terminal error. The install stops during dependency resolution, and the fix belongs to the package manager rather than to the app.

Chocolatey is marked unofficial:

```powershell
choco install microsoft-windows-terminal
```

Upgrades are a separate command:

```powershell
choco upgrade microsoft-windows-terminal
```

A packaging fault here is reported on the Chocolatey package page and handled through their triage process, not in this repository, so a broken install can sit outside the project that ships the binary.

Scoop is also unofficial, and needs the extras bucket added first:

```powershell
scoop bucket add extras
scoop install windows-terminal
```

Updates run through scoop rather than through the app:

```powershell
scoop update windows-terminal
```

Scoop problems go to the Scoop Extras issues page. The shared consequence across both community channels is the same: the person who maintains the package is not the team that writes the code, and the two move on different schedules.

## A manual msixbundle install never checks for updates again

For anyone blocked from the Store, released builds are downloadable from the repository's Releases page. The file to grab is Microsoft.WindowsTerminal_<versionNumber>.msixbundle from the Assets section. Double-clicking it normally starts the app installer, and when that fails the documented fallback runs at a PowerShell prompt:

```powershell
# NOTE: If you are using PowerShell 7+, please run
# Import-Module Appx -UseWindowsPowerShell
# before using Add-AppxPackage.

Add-AppxPackage Microsoft.WindowsTerminal_<versionNumber>.msixbundle
```

That comment is not decoration. On PowerShell 7 and later, Add-AppxPackage is not loaded by default, so the import has to happen first or the command is not recognised at all.

Two costs follow from installing this way. On older Windows 10 builds the install can stop with an error about missing framework packages, which points at the VC++ v14 Desktop Framework Package rather than at anything wrong with Terminal. The larger cost is stated plainly in the same note: a manual install does not auto-update, so every fix and improvement has to be fetched and reapplied by hand, indefinitely.

## Canary splits into an installer that updates and a ZIP that does not

Canary is a nightly build tracking main, offered so you can reach features before they reach Preview. The README calls it the least stable offering and warns that you may find bugs before the team has.

Two distributions come out of that channel, and they behave differently. The App Installer distribution supports automatic updates and covers x64, arm64 and x86, but due to platform limitations it works only on Windows 11. The Portable ZIP is x64, runs on Windows 10 19041+ as well as Windows 11, and neither automatically updates nor automatically checks for updates.

The consequence is sharp for Windows 10 users. Clearing the 19041 floor does not get you the updating channel, so anyone on Windows 10 who wants Canary is pushed onto the ZIP. A ZIP that never checks for updates will sit on whatever nightly was unpacked, with nothing to signal that a newer one exists. Canary is where regressions land first, so the copy that never refreshes is also the copy most likely to be stranded on a commit that has since been fixed.

## Stable and Preview ship on the same day with separate version lines

The release history shows two trains that advance independently. On 16 July 2026 the project published Windows Terminal v1.24.11911.0 and Windows Terminal Preview v1.25.1912.0 on the same day, and an earlier Preview, v1.25.1322.0, on 13 May 2026.

Preview numbers do not continue the stable line, so the larger figure is not an upgrade of the smaller one. A reader who sees 1.25 and assumes it supersedes 1.24 is reading the two channels as one sequence, and they are not. The consequence reaches anything that pins a version, because a script or a managed deployment has to name the channel as well as the number.

Behind those tags, main took its last push on 24 September 2026, more than two months after the newest release listed above. Anyone building from the default branch is therefore running code that no tagged build has shipped, and that gap is exactly the code the nightly Canary build is assembled from.

## The console API examples live in samples/, not in a package

This is a C++ codebase first, and what it offers someone who wants to program against Windows console features is the samples tree. Three directories sit there: samples/ConPTY/, samples/PixelShaders/ and samples/ReadConsoleInputStream/. They are worked examples of consuming the Windows Console APIs.

The repository publishes no library or package for a third-party application to link against. That is the practical limit: to use a console API from your own program you read an example and adapt it, rather than adding a dependency and pinning its version. For an evaluation of whether this project serves your use case, that distinction decides the answer. If you need a redistributable console library, this tree is not the source of one, however complete the samples look.

A second boundary sits beside it. The documentation an end user needs is not carried here at all. Settings, keybindings and the Console API reference live in the separate documentation repositories, and the font has its own repository too.

## A build that runs but looks like the old console is a filed FAQ

The README's table of contents carries a FAQ entry titled "I built and ran the new Terminal, but it looks just like the old console." That question being filed as a known outcome, rather than left to chance, tells you the gap between building successfully and building the thing you expected is routine.

The root layout explains why it is easy to hit. Two full solution files sit at the top, OpenConsole.slnx and Scratch.sln, alongside a filtered solution, conhost.slnf, plus a spread of root property files such as Directory.Build.props, Directory.Build.targets, common.openconsole.props and custom.props that decide what gets built. Reaching for the wrong one yields a binary that runs and still behaves like the console host you were trying to replace.

The same table of contents routes contributors to Prerequisites, to separate build instructions for PowerShell and for Cmd, and to a Running & Debugging section, all grouped under Developer Guidance. A from-source build is a multi-step setup rather than one command, and this article does not reproduce those steps. For an end user evaluating the project, none of it applies: you take the Store package and never open a solution file.

## Conclusion

Take this project if you run Windows 10 build 19041 or later and want a terminal that keeps itself current, where the Store package or a recent winget client is the shortest route. Skip the manual msixbundle unless the Store is genuinely unavailable, and accept that you then own every future update by hand. Before committing to a channel, check the Windows build number on the machine and decide which of the two release lines you are pinning, because Preview numbers do not continue the stable line.

## FAQ

### What is a terminal in a computer?

In this repository the terminal is the Windows Terminal app, which ships in the same tree as conhost.exe, the original Windows console host, along with the components the two share. Windows Terminal is the newer front end, and the repository carries the source for both.

### What is the terminal app used for?

Windows Terminal is the graphical shell for running command-line programs on Windows, and it requires Windows 10 2004, build 19041, or later. It is distributed through the Microsoft Store, winget, Chocolatey, Scoop, or a manual msixbundle download.

### Is terminal good for coding?

The repository is a C++ codebase with samples/ directories showing how to consume the Windows Console APIs, including ConPTY, PixelShaders and ReadConsoleInputStream. For day to day use the deciding factor is update behaviour, since only the Microsoft Store and the Canary App Installer update automatically.

### how to install terminal in windows

The Microsoft Store route is the preferred one and upgrades automatically. Otherwise install the Microsoft.WindowsTerminal package with winget, microsoft-windows-terminal with Chocolatey, or windows-terminal from Scoop's extras bucket. A manual msixbundle install does not update on its own.

### how to use terminal in windows

The repository does not carry the user documentation. It points at learn.microsoft.com/windows/terminal, with a MicrosoftDocs/terminal repository for contributing to those docs and a MicrosoftDocs/Console-Docs repository for the Console API reference.

## Sources

- [Official README](https://github.com/microsoft/terminal#readme)
- [Project repository](https://github.com/microsoft/terminal)
- [Release notes](https://github.com/microsoft/terminal/releases)

---

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