microsoft/terminal: the Windows Terminal and conhost source tree
The new Windows Terminal and the original Windows console host, all in the same place!
At a glance
- What is it?
- Microsoft's repository holds both the modern Windows Terminal app and the legacy console host, plus the shared components between them. It is a C++ codebase for people who build or extend Windows command-line infrastructure, not a general-purpose terminal for other platforms.
- Who is it for?
- Adopt it if you target Windows 10 2004 (build 19041) or later and want the documented Store, winget, Chocolatey, or Scoop path to a modern terminal, or if you need to read the C++ behind conhost.exe and the shared components. Skip it if your machines are older than build 19041, if you need a terminal on macOS or Linux, or if you want a stable API surface rather than a Preview channel that ships features first.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Two products, one repository, and a shared component layer
The repository contains the source for Windows Terminal, Windows Terminal Preview, the Windows console host (conhost.exe), the components shared between those projects, ColorTool under src/tools/ColorTool, and sample projects that show how to consume the Windows Console APIs. That combination is the point. conhost.exe is the window that has hosted console applications on Windows for years; Windows Terminal is the newer app that renders the same console sessions through a different front end. Because both live here, a change to terminal emulation logic or to the console API surface can be made once and consumed by both.
Who this is for is narrower than the download numbers suggest. If you install Terminal from the Store, you are a user of a shipped product and the source tree is irrelevant to you. If you write console applications, the samples directory is the interesting part, because it documents how to consume the Windows Console APIs rather than how to use the app. If you are building or debugging conhost.exe itself, or the pseudoconsole layer that sits between a console application and a terminal front end, this is the canonical place. The README also points at related repositories: the Windows Terminal documentation, the Console API documentation, and the Cascadia Code font, each maintained separately.
How the console host and the terminal app relate
The README's Terminal & Console Overview section splits the codebase into Windows Terminal, the Windows Console Host, shared components, and the work of creating the new Windows Terminal. The structure matters because it explains why this is a C++ repository with a Visual Studio solution rather than a small utility. OpenConsole.slnx is the main solution at the top level, with conhost.slnf as a solution filter for the console host alone, and Directory.Build.props and Directory.Build.targets carrying shared MSBuild configuration. Dependencies are declared in vcpkg.json, so the native library set is pinned through vcpkg rather than vendored.
One consequence of hosting both front ends is visible in the README's own FAQ entry: if you build and run the new Terminal and it looks just like the old console, that is a documented confusion, not a bug report you need to file. The two binaries are distinct and the build output can put you in front of the wrong one. Another consequence is that the shared components are the real product boundary. Terminal features that depend on console host behaviour cannot ship on their own, and console host fixes that predate the terminal app still have to be validated against it. If you are evaluating this repository as a dependency rather than as a program, the shared components are what you would be reading, and the README does not document a supported embedding API for them.
Installing Windows Terminal with winget, the Store, or an msixbundle
The README states that Windows Terminal requires Windows 10 2004 (build 19041) or later. The recommended path is the Microsoft Store, because that keeps you on the latest version with automatic upgrades. If you cannot use the Store, the repository's Releases page carries the manual builds. Download the Microsoft.WindowsTerminal_<versionNumber>.msixbundle file from the Assets section and double-click it; the app installer should run. If that fails, the README gives this PowerShell fallback:
# NOTE: If you are using PowerShell 7+, please run
# Import-Module Appx -UseWindowsPowerShell
# before using Add-AppxPackage.
Add-AppxPackage Microsoft.WindowsTerminal_<versionNumber>.msixbundleFor package manager users, the README documents winget with the Microsoft.WindowsTerminal package. Run this and you should see winget resolve and install the stable release:
winget install --id Microsoft.WindowsTerminal -eThe README notes that dependency support requires WinGet version 1.6.2631 or later, and that installing the stable release 1.18 or later needs that updated client. Two unofficial channels are also listed. Chocolatey installs the microsoft-windows-terminal package, and Scoop installs windows-terminal from the extras bucket:
choco install microsoft-windows-terminal
scoop bucket add extras
scoop install windows-terminalEach of those has its own upgrade command, choco upgrade microsoft-windows-terminal and scoop update windows-terminal. The README explicitly labels both as unofficial and routes package problems to the Chocolatey package page and the Scoop Extras issues page rather than to this repository.
There is a third channel worth knowing about before you pick one. Windows Terminal Canary is described as a nightly build from the main branch, intended for trying features before they reach Windows Terminal Preview, and the README calls it the least stable offering. It ships as an App Installer distribution that auto-updates but only works on Windows 11, and as a Portable ZIP that works on Windows 10 (19041+) and Windows 11 but does not check for or apply updates. That split is a real constraint: if you are on Windows 10 and want the nightly channel, you get the non-updating ZIP.
Manual installs do not update themselves
The README's note on manual installation is the limitation most likely to bite. When you install Terminal by hand from an msixbundle, the app will not auto-update when new builds are released, so you have to install each new release yourself to receive fixes and improvements. The same applies to the Portable ZIP Canary distribution, which the README says will not automatically update and will not automatically check for updates. Only the Store path and the Canary App Installer path give you automatic updates, and the latter is Windows 11 only.
The second limitation is the framework dependency. The README warns that a manual install may require the VC++ v14 Desktop Framework Package, and that this should only be necessary on older builds of Windows 10 and only if you get an error about missing framework packages. That is a narrow case, but it is the kind of failure that looks like a broken download rather than a missing runtime.
A third boundary is the platform floor itself. Build 19041 is not negotiable, and nothing in the README suggests a path for older systems. If you administer a fleet that mixes Windows 10 releases, the install story is not uniform across it, and the Canary channel is not an escape hatch because its App Installer variant is Windows 11 only. The README also does not document rollback to a previous Terminal version, so plan upgrades around that silence rather than assuming a supported downgrade path exists.
Where this repository is the wrong place to look
If you want a terminal for macOS or Linux, this repository will not help you. It is Windows-only by construction: the console host is a Windows component, the installers are msixbundle and App Installer packages, and the package manager recipes are winget, Chocolatey, and Scoop. Searching for a cross-platform terminal here is a category error.
If you want to contribute documentation rather than code, the README sends you elsewhere: the Windows Terminal documentation lives in its own repository, as does the Console API documentation. Filing a docs issue against this tree is the wrong destination, and the README says so by listing them under Related repositories.
If you are looking for a stable, versioned API to build a terminal front end against, the repository points at samples rather than a contract. The samples directory contains ConPTY, PixelShaders, and ReadConsoleInputStream examples, which show how to consume Windows Console APIs, but the README does not describe a supported embedding interface for the shared components. Treat the sample code as a demonstration of the API shape, not as a compatibility promise. And if you want a terminal that ships on a predictable cadence with no Preview builds, note that this repository also produces Windows Terminal Preview and Canary, so the release stream you land on depends entirely on which channel you installed from.
Maintenance, licensing, and what an upgrade costs you
The repository is not archived, and the last push was on 2026-07-16. The same date carries three releases: Windows Terminal Preview v1.25.1912.0, Windows Terminal v1.24.11911.0, and an earlier Preview, v1.25.1322.0, dated 2026-05-13. The stable and Preview channels moving on the same day is consistent with the repository's structure, where both front ends are built from one tree.
Upgrade cost depends on the channel. Store installs upgrade automatically, so the cost is whatever behaviour changed between releases. Manual msixbundle installs push that work onto you: the README states plainly that you need to regularly install the latest Terminal release to receive fixes and improvements. Canary is the highest-churn option, described as the least stable offering, where the README warns you may discover bugs before the team has found them. If you run Canary on Windows 10, you are on the Portable ZIP, which means you also own the update process and get no update checks at all.
The licence is MIT, with a separate NOTICE.md at the top level. MIT is permissive and permits reuse and redistribution with the licence and copyright notice retained; NOTICE.md is where third-party attributions for the bundled dependencies live, which matters because vcpkg.json pulls in a native dependency set. That is a description of the files present, not legal advice. If you redistribute a build, read LICENSE and NOTICE.md yourself, and note that the Microsoft Store and winget packages are distributed under their own terms through those channels.
Editorial conclusion
Adopt it if you target Windows 10 2004 (build 19041) or later and want the documented Store, winget, Chocolatey, or Scoop path to a modern terminal, or if you need to read the C++ behind conhost.exe and the shared components. Skip it if your machines are older than build 19041, if you need a terminal on macOS or Linux, or if you want a stable API surface rather than a Preview channel that ships features first. Before committing, check the Releases page for the current Microsoft.WindowsTerminal_<versionNumber>.msixbundle asset, confirm your WinGet client is 1.6.2631 or later if you install the stable release 1.18 or later, and read the repository's SUPPORT.md and SECURITY.md for how issues are routed.
Frequently asked questions
What is the Windows Terminal app used for?
It is the modern terminal application built from this repository, and it renders console sessions alongside the legacy Windows console host, conhost.exe, which is also built here. The repository additionally contains the components shared between the two and sample projects that show how to consume the Windows Console APIs.
How do I install Windows Terminal on Windows?
The README recommends the Microsoft Store, which keeps you on the latest version with automatic upgrades. Alternatives are the Microsoft.WindowsTerminal_<versionNumber>.msixbundle from the Releases page, winget install --id Microsoft.WindowsTerminal -e, or the unofficial Chocolatey and Scoop packages. Windows 10 2004 (build 19041) or later is required.
Is Windows Terminal good for coding?
The repository does not make claims about coding workflows, so that judgement is not answerable from what it documents. What it does document is that the app hosts console sessions, that a stable and a Preview channel ship separately, and that it requires Windows 10 2004 (build 19041) or later.
How do I use Windows Terminal in VS Code?
The repository does not document a VS Code integration, so there is nothing here to confirm about that setup. The install and configuration material covers the Store, msixbundle, winget, Chocolatey, and Scoop channels only.
Community notes