# mintty: the Cygwin terminal that also serves MSYS and WSL

> Mintty is a terminal emulator written in C for Cygwin, MSYS and WSL, distributed as a Cygwin package and as source with a Makefile that drives the whole release. This looks at how it is built and packaged, and at the unusual licence situation its bundled components create.

**mintty/mintty** — The Cygwin Terminal – terminal emulator for Cygwin, MSYS, and WSL

- Repository: https://github.com/mintty/mintty
- Website: http://mintty.github.io/
- Stars: 1,796 · Forks: 202
- Language: C
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mintty-mintty

## A terminal for the Unix-likes that run on Windows

Mintty is the Cygwin Terminal, and also the terminal emulator for MSYS, which covers Msys2 and old MSYS. The project description adds WSL to that list, and the homepage is mintty.github.io.

The distinction the project cares about is the one between a terminal and a console, and it comes up in the bug reporting guidance. Before reporting an issue about character interaction with an application, the readme asks you to check the issue with at least one other terminal, xterm or urxvt, and perhaps the Cygwin Console, and it suggests getting a proper understanding of the role of a terminal as explained in a linked discussion of the difference between a terminal, a shell, a tty and a console.

That guidance is a fair description of the project's own position. Mintty is not a shell and it is not a tty implementation, it is the window that renders what a pty produces and the thing that turns your keystrokes into bytes. The reason it exists at all is that the Windows console does not do what a Unix terminal is expected to do, and the Cygwin, MSYS and WSL worlds all needed one that did.

The documentation is split three ways, which tells you the audience. The homepage carries the introduction, a features overview and screenshots, the wiki holds the detailed hints and specific issues, and the manual page holds the comprehensive general documentation.

## Five licence files at the root, and why that matters

The repository root carries `LICENSE`, `LICENSE.GPL`, `LICENSE.Oxygen`, `LICENSE.PuTTY` and `LICENSE.bundling`, and that list is the single most important thing to notice about the project.

The reason is in the names. The project is listed in the repository metadata as carrying a custom licence that GitHub cannot classify, which is what happens when a distribution is the combination of several licences rather than one. The other files cover the parts that came from elsewhere: the PuTTY licence covers the code derived from the PuTTY terminal, the Oxygen licence covers the icon and theme material associated with the Oxygen icon set, the GPL file covers components distributed under the GNU General Public License, and the bundling file covers the terms for the distribution as a whole.

The practical consequence is that anyone redistributing mintty, whether as a Cygwin package or inside a larger product, has to satisfy the terms of the most restrictive component, and the GPL file is presumably why. The main licence file on its own tells you nothing about the distribution.

This is not a defect and it is not unusual for a project of this age, which has been accumulating third party code for a long time. It is a documentation task, and the files are in the repository for exactly that reason. The point for an evaluator is that a licence answer for mintty is not "MIT", it is "read the five files".

## The Makefile is the release machine

The build and release process is entirely in the root Makefile, and its comment block is the best documentation of the project's workflow.

The interesting targets are `exe`, which is just the executable and is the default, `tar` for a source tarball, `release` for a new release with checks, language files and a git tag, `pkg` for a Cygwin package, `upload` to upload the Cygwin packages for publishing, and `ann` to create the Cygwin announcement mail. The auxiliary targets are `html` and `pdf` for versions of the manual page, `clean`, `_` to create the language translation template and update the translation files, and `install` to install locally into `$(DESTDIR)/`. The `zip` target is marked obsolete, left over from the days of standalone releases.

The mechanics underneath are worth a look, because they explain how a C project with translations and a Cygwin package keeps its versions straight. The version number is derived from `src/appinfo.h` by running it through the C preprocessor, and the changelog version is extracted from `wiki/Changelog.md` with sed. The git version comes from a script, `src/mkvertag`, with a comment explaining why it is not assigned with `:=`, because that would give the version before tagging. Adding a file to the distribution means adding it to the `arch_files` variable and to `cygwin/mintty.cygport`.

The build also has an AppVeyor configuration for Windows, and the `cygwin/` directory holds the Cygwin packaging material, with the `.cygport` file named in the instructions.

## What the tree contains, and what each directory is for

The layout of the repository explains the shape of the project.

`src/` is the code, and it holds the pieces the Makefile reaches into, `appinfo.h` for the version and `mkvertag` for the git version. `lang/` holds the translation files, which is why the Makefile has a `_` target to create the translation template and update them, and why the `release` target mentions language files as part of a release. `themes/` holds the colour themes, `icon/` the icons, and `sounds/` the terminal bell sounds, which is a small detail that says a lot about the project's priorities.

`docs/` holds the manual page sources, `wiki/` the wiki content that the build also reads for the changelog, `tools/` the helper scripts, and `config.template` is the configuration template. The `attic/` directory is the conventional name for code that is kept but no longer built. `cygwin/` holds the Cygwin packaging, and `appveyor.yml` the Windows CI configuration.

There is an `INSTALL` file at the root as well as a `VERSION` file, both of which are outputs of the build rather than hand-maintained sources, since the Makefile writes the version into `VERSION` as part of the `ver` target.

## Where mintty is the wrong tool

Four limits are worth stating.

The first is the platform. Mintty is a Windows program. It emulates a Unix terminal for the Cygwin, MSYS and WSL environments, but a Linux or macOS user has a native terminal already and no reason to run this. It is also not a terminal multiplexer, so if you want split panes and session persistence you need something else, and it is not a shell, so the prompt, the job control and the scripting all come from whatever shell you launch inside it.

The second is that it will not make native Windows tools behave like Unix tools. The readme's own advice to test a character interaction bug against xterm, urxvt and the Cygwin Console is a reminder that a rendering difference in mintty is a bug in mintty, while a difference in how an application reacts to a pty is a difference in the application. The distinction is worth keeping in mind before spending an evening on the wrong side of it.

The third is the contribution policy, which is unusually strict and stated in capitals. The repository policy is no unsolicited pull requests, and the readme asks you to discuss a proposal in an issue first, or on the Cygwin mailing list, or with the maintainer. That is a real constraint on how you work with the project, and it is a deliberate choice by a maintainer who has been doing this for a long time.

The fourth is that the issue tracker has history. Bugs reported to the previous repository at Google Code before June 2015 were migrated to the current tracker, which means searching for an old symptom may surface a very old thread with a very old answer. The wiki, which the readme points to for detailed hints and specific issues, is the more useful place to look for current behaviour.

## A steady release line, and a project that has outlived its hosting

The release record is regular for a project of this age. 3.8.1 was published on 2025-09-18, 3.8.2 on 2026-02-15, and 3.8.3 on 2026-06-08, with the last push to the repository on 2026-10-04. The changelog lives in the repository, in `wiki/Changelog.md`, which is where the Makefile reads the version from, and the version is also printed in the `VERSION` file and the `appinfo.h` header.

The project is not archived, and the fact that it survived a hosting change is worth noting. Mintty was originally hosted on Google Code, and the readme notes that bugs reported there before June 2015 were migrated into the current GitHub issue tracker. Moving a project and its issue history off a platform that was being shut down is not trivial, and the fact that the build, the packaging, the translations and the release automation all still work from a Makefile is a sign of a project with a maintainer who cares about the release path rather than only the source.

For a user, the practical answer is that the Makefile builds a Cygwin package from the `cygwin/` directory. The documentation to read is the manual page for the comprehensive reference and the wiki for the hints and the specific issues that the manual does not cover.

## Conclusion

mintty fits a Windows developer who needs a terminal that behaves like a Unix terminal rather than a console, whether that is Cygwin, MSYS2 or WSL, and it fits a packager who wants a terminal with a self-contained build and no runtime dependencies. It does not fit a Linux or macOS user, since it is a Windows program, and it is the wrong tool if you are looking for a terminal multiplexer, a shell, or a console replacement for native Windows tools. Before you redistribute it, read the licence files at the repository root, because `LICENSE`, `LICENSE.GPL`, `LICENSE.Oxygen`, `LICENSE.PuTTY` and `LICENSE.bundling` sit side by side, and before you contribute, open an issue first, because the repository policy is no unsolicited pull requests.

## FAQ

### What is mintty used for?

Mintty is a terminal emulator for the Cygwin, MSYS and WSL environments, giving them a Unix-style terminal window instead of the Windows console. It is the Cygwin Terminal and the MSYS terminal emulator for Msys2 and old MSYS.

### How do I build mintty from source?

The root Makefile is the entry point, and the `exe` target, which is the default, builds just the executable. Other targets cover the source tarball, the release with checks and a git tag, the Cygwin package, and the Cygwin upload and announcement steps.

### What licence is mintty released under?

The distribution combines several licences, with LICENSE, LICENSE.GPL, LICENSE.Oxygen, LICENSE.PuTTY and LICENSE.bundling all present at the repository root, which is why the licence is listed as a custom one. Anyone redistributing it should read those files rather than assume the terms of the main licence file cover the whole distribution.

### Can I send a pull request to mintty?

The stated repository policy is no unsolicited pull requests. The readme asks you to discuss a proposal in an issue first, or on the Cygwin mailing list, or with the maintainer, before contributing code.

### Where should I look for mintty documentation?

The homepage carries the introduction, features overview and screenshots, the wiki holds detailed hints and specific issues, and the manual page holds the comprehensive general documentation. Bugs and enhancement requests go to the issue tracker, which also holds migrated reports from the old Google Code repository.

## Sources

- [Issues](https://github.com/mintty/mintty/issues)
- [mintty/mintty on GitHub](https://github.com/mintty/mintty)
- [Project website](http://mintty.github.io/)
- [README](https://github.com/mintty/mintty/blob/master/README.md)
- [Releases](https://github.com/mintty/mintty/releases)

---

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