con: a terminal emulator that puts the AI harness second

The pitch is AI help only when it earns its place

The positioning is unusually specific about who the project is for. The tagline is a terminal emulator with an AI harness, nothing more, and the why section says it plainly: con is for people who want a serious terminal first and AI help only when it earns its place, and if you are an old-school terminal user who only wants enough AI harness when needed, nothing more or less, this is for you. What it claims to do has three parts. A terminal that is fast and elegant. A built-in AI harness that can read context, ask before acting, and work directly in the terminal you can already see, which is the detail that separates it from a chat window next to a terminal. And terminal-native workflows for command line work, with ssh, tmux and coding-agent-aware orchestration named as the intended settings. Nothing on that list is a chat feature, and the ordering matters, because a terminal that degrades without its agent is a different product from one that does not.

macOS is supported, Windows and Linux are tracked separately

The status section does not use one label for three platforms, which is the most useful thing on the page. con is in active beta development. macOS is fully supported, at beta. Windows is early beta, with its own public tracker at issue 34. Linux is preview, with its tracker at issue 18. Those three labels mean three different things for a team deciding whether to standardise on it, and having separate trackers keeps a Windows bug from being closed as a duplicate of a macOS one. Feature support follows the same split. Quick Terminal, the optional drop-down terminal, is marked not available on Windows and Linux and is enabled on macOS through a global shortcut in Settings then Keys, or from the command palette or the View menu while con is frontmost. It is off by default. The release cadence is beta-heavy as well, with v0.1.0-beta.117 and v0.1.0-beta.116 both published on 2026-09-29 and v0.1.0-beta.115 on 2026-09-28.

Smart mode guesses whether you typed a command or a request

The input bar has three behaviours and the interesting one is the first. Smart mode decides whether your text is a shell command or an agent request, which means the same box serves both a terminal and an assistant without a mode prefix. Command mode runs shell commands, and with multiple panes open it brings up a pane mini map so you can choose the focused pane, all panes, or a selected set, which is how a broadcast goes from one keystroke to a chosen subset of panes rather than everywhere. Agent mode sends the text straight to the built-in agent. The key map is split by platform in a way worth noting before you memorise it. Focus switching between the terminal and the input is command-I on macOS but control-shift-I on Windows and Linux, the agent panel is command-L against control-shift-L, and the bottom input bar is control-backtick on both. Cycling the bottom bar mode is command-semicolon on macOS and control-semicolon elsewhere.

The Windows binary is con-app.exe because CON is a reserved DOS name

The build recipes explain more about the project than any feature list. The justfile runs on just, sets `cmd.exe` with `/c` as the Windows shell so recipes work in a plain Developer Command Prompt without Git Bash, Cygwin or a POSIX shell on PATH, and uses the `w*` cargo aliases on Windows for one specific reason: `CON` is a reserved DOS device name, so the Windows binary is feature-gated as `con-app.exe`. Architecture is a just variable that defaults to empty, with each Unix recipe auto-detecting through `uname -m` inside the shell body, while Windows recipes never reference it so `uname` is never invoked there. The release channel variable defaults to `stable` and accepts stable, beta or dev, which is worth noticing against a README that describes active beta development. One layout constraint is stated as a hard rule: `con-cli` must be a sibling of the con binary, because the handoff launch helper and its pre-dispatch protocol gate resolve `con-cli` next to `current_exe()`.

GPUI is pinned to a snapshot because two snapshots are incompatible types

The workspace manifest explains the dependency strategy better than a paragraph could. It is nine crates, `con-app`, `con-core`, `con-paths`, `con-terminal`, `con-ghostty`, `con-agent`, `con-cli`, `con-process` and `con-test`, with `con-app` as the default member, edition 2024 and workspace version 0.1.0. The UI layer does not depend on Zed's GPUI directly. It depends on the `gpui-pre-*` crates.io snapshots pinned with exact version 0.3.7, which the comment identifies as a specific Zed commit, and the reason for the pin is spelled out: any snapshot may change the GPUI API, and two snapshots in one tree are incompatible types. The component library is upstream `gpui-component` at exactly 0.7.0, with a comment forbidding local 3pp paths. Even the text buffer crate is an exact pin, `ropey` 2.0.0-beta.1, built with metric line and metric utf16 support. The agent harness is `rig-core` 0.40.0 with default features off and rustls on.

Two install channels per platform, one official and one community

Every platform has an official path and, on two of them, a community package manager path, and the difference between them is spelled out rather than left to be discovered. On macOS the Homebrew cask comes from a beta tap:

brew install --cask nowledge-co/tap/con-beta

That cask installs the application and exposes `con-cli` on your PATH for automation. The alternative for macOS is the official script, which installs the app into `/Applications` and links `con-cli` into `~/.local/bin`, or a DMG from the releases page. Linux uses the same script but installs both `con` and `con-cli` into `~/.local/bin`, with a tarball as the alternative. Arch users get a community package:

yay -S con-bin

It is maintained on AUR by czyt, `paru` works too, and the README says to use the official installer if you need the newest beta immediately after a release. Windows has the same shape with a community bucket maintained by EFLKumo:

scoop bucket add jam https://github.com/EFLKumo/jam
scoop install jam/con-terminal

That manifest installs a portable con and adds `con-app` and `con-cli` to your PATH.

Configuration is Ghostty's, living in con.conf

The configuration model is inherited rather than invented, and the documentation page for it is an implementation record under `docs/impl/`. Ghostty terminal settings and Con-specific behaviour are configured in the same file, `con.conf`, which is named `con-terminal.conf` on Windows, so the platform difference is a filename rather than a schema. The rest of the documented surface is oriented around repeatable work rather than appearance. Skills and workflows turn repeated terminal routines into project-level or personal slash commands, which is the mechanism for encoding a routine you would otherwise retype. Workspace layout profiles save a project layout, reopen it later, or share it with a team, so a multi-pane arrangement becomes something versionable rather than something you rebuild by hand. `con-cli` is documented as the surface for building scripts, test runners and external agent orchestrators on top of con, which is how the terminal is meant to be driven by other tools rather than only by a person at the keyboard.

The credits section is effectively the architecture diagram

The dependency list reads like a statement of what con does not build. Ghostty provides the terminal runtime and rendering foundation that powers the embedded terminal surfaces, so the emulator core is not written from scratch. GPUI comes from the Zed team as the native GPU UI framework the shell is built on, and gpui-component comes from the Longbridge team as the component library that accelerates much of the UI layer. Rig is the Rust agent framework behind the AI harness, which is the clearest single answer to what the harness is. Phosphor Icons supplies the icon system. Each of those is credited as an upstream project relied on directly, which matters for a project whose value proposition is fast and elegant: on a terminal that must feel native on macOS, borrowing the rendering path is the difference between a year of work and a shell. The repository structure backs the same story, with a `benchmarks/` directory for measurement, a `postmortem/` directory for written incident records, `docs/study/` for research notes, and DESIGN.md for product direction and system design.

Editorial conclusion

con is worth a try if your terminal work already runs through ssh, tmux and coding agents, because that is the workflow it names and the one its pane, surface and CLI features are shaped around. Three things to weigh. The platform status is uneven, with macOS fully supported while Windows is early beta and Linux is preview, each with its own public tracker, so do not standardize on it across a mixed fleet yet. The AI harness is the differentiator and also the risk, since the agent works in the same surface you are watching and reads context, so the approval step is the thing to configure deliberately. And the build pins Zed's UI framework to an exact crates.io snapshot, which means a maintainer has to bump GPUI and gpui-component together on purpose rather than letting a patch release move underneath.

Frequently asked questions

Official sources

1. License: MIT
2. nowledge-co/con-terminal on GitHub
3. Project website
4. README
5. Releases