Connexio makes the project, not the window, the unit of organisation

The project becomes the container, and the window disappears

The stated problem is not that terminals are inconvenient but that they are unlabelled. Working across several projects leaves dozens of windows and tabs with no clear organisation, and the two questions that follow are which terminal belongs to which project and where a particular server was left running.

Connexio's answer is to make the project the unit. Each project gets a workspace containing its own terminal tabs, and the tab itself can be renamed and dragged into a different position. Projects reorder the same way and can be dragged between groups.

Persistence is what makes the grouping worth the setup. Tabs, the pane layout and the active project all survive a restart of the application, so reopening it puts you back where you were rather than at an empty first screen. That single behaviour is what converts a grouping feature into a workspace feature.

The shell is chosen per environment rather than configured by hand, with a picker that detects what is installed: PowerShell, CMD, Git Bash, WSL, Zsh and Fish are all named.

Rendering and appearance are both behind a settings toggle

Terminal rendering is hardware accelerated through a WebGL path, and unlike most accelerated rendering this one can be switched off in settings. That matters more than it sounds: a GPU-accelerated renderer occasionally behaves differently from the plain path on remote desktop or inside unusual terminal emulators, so being able to fall back without uninstalling is a practical escape hatch.

Three built-in themes ship, named Dark, Light and Midnight Ocean, and the documentation is explicit that the themes cover terminal colours rather than only the surrounding chrome.

The settings surface covers font size, font family, cursor style, scrollback length, a copy-on-select behaviour, and the default shell. A frameless custom titlebar carries the application version.

Panels are resizable, so an editor and a terminal can sit side by side rather than in separate windows. The editor itself is CodeMirror 6 with language support for JavaScript, TypeScript, HTML, CSS, Python, Rust, JSON and Markdown, a file explorer provides the tree with a context menu and inline actions, and a live web preview can be opened as another workspace tab.

The task runner reads four manifest formats instead of a config file

Rather than asking you to describe your scripts, the task runner inspects the project it is looking at and detects candidates from four files: the Node package manifest, a Makefile, the Cargo manifest, and the Python project manifest. Whatever it finds becomes a one-click entry.

That design has a clear consequence. There is nothing to configure, so there is also nothing that can be wrong, and the set of available tasks changes automatically as you add a script. The trade-off is that you only get what those four formats describe, so a bespoke script behind some other name stays invisible.

Two smaller productivity features sit alongside it. Pinned commands store frequently used commands per project with full create, read, update and delete handling and drag reordering. The command timer measures how long a command ran and raises a notification when a long-running one finishes, which is the case that matters when you have walked away from a long build.

Both are per-project rather than global, on the reasoning that the command you want pinned in one repository is rarely the one you want in another.

Git sits in the workspace header rather than in a separate tool

The git integration is scoped per project and surfaced in the workspace itself.

Status is live and specific about what it reports: current branch, how far ahead or behind the remote the project is, and separate counts for modified, staged and untracked files. Those three counts are separated rather than summed, so an untracked file cannot hide inside a general modified count.

Switching branches happens from the workspace header, which is a small decision with a large convenience attached: it means changing branch does not require leaving the project view or opening another application. A commit box stages and commits from the same surface, and commit history is browsable per project.

The backend doing this work is Rust. The stated division of labour is that the native side owns the pseudo-terminal, git, SSH and the file system, while the interface is React with TypeScript and Zustand for state. Terminal drawing itself goes through xterm.js with its WebGL addon.

So the operations that need to touch a real process or a real file system are native, and the panels that display them are web technology.

Remote access is token based and can borrow your Tailscale addresses

The connectivity group is where the project reaches beyond the local machine.

Remote access opens a mobile workspace guarded by trusted-token login, with remote terminal controls once you are in. The SSH manager stores connections both per project and globally, and connects in one click using either key or password authentication, so a jump host for one repository does not have to be retyped in another.

For private network reach there is Tailscale support, which detects the machine's Tailscale addresses and uses them to generate remote URLs instead of exposing anything publicly.

Two integrations are adjacent but unrelated to security. An AI chat lives in a side panel with a configurable model integration. Discord rich presence publishes what you are working on.

Updates arrive through the Tauri updater plugin, checking GitHub Releases and installing in one click.

The QR code dependency in the package manifest is consistent with the mobile login story, where scanning a code from a phone is a more practical way to transfer a trusted token than reading one aloud.

Two custom scripts police file size and import direction

Alongside the ordinary lint and test commands, the project defines two architecture guards that are not standard tooling.

One runs a script that enforces a maximum line count, and the other runs a script that checks feature imports. Both are plain Node scripts reading the project's own configuration, wired in as npm tasks. That combination, a file size ceiling plus a rule about which parts of the codebase may import which other parts, is a deliberate attempt to keep a growing desktop application from turning into one unbounded frontend directory.

The rest of the toolchain is deliberately not the default. Formatting and linting run through a Rust-adjacent formatter and linter rather than the usual JavaScript equivalents, with a check mode that reports without writing. Tests run under Vitest against a configuration file in the config directory. A Husky prepare hook installs the git hooks on install.

The conventions are written down as well as enforced. AGENTS.md holds written conventions for AI agents and contributors, and a style guide in the docs directory is described as the canonical source of design tokens and utility classes.

Seven Linux packages stand between you and a build

Building from source needs Node.js 18 or newer and current stable Rust from rustup, then platform dependencies. On macOS that is a single command installing the Xcode command line tools. On Windows it is the WebView2 runtime, which is normally already present on Windows 10 and 11, plus the Visual Studio C++ build tools.

Linux is the longest list, and it is specific enough to be worth quoting in full:

sudo apt install libwebkit2gtk-4.1-dev build-essential curl wget file libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev

Seven packages, covering the web view, the toolchain, the tray icon integration and the SVG library.

Release is driven by npm versioning. A patch bump publishes a stable tag, and a preid of dev produces the dev channel, with alpha and beta preids also supported. Pushing any version tag triggers GitHub Actions to build all platforms and publish the release, which is what makes the updater plugin's one-click path possible.

Editorial conclusion

Connexio suits someone whose terminal sprawl is really a project organisation problem, since making the project the container is what turns a dozen unrelated windows back into a small number of workspaces you can return to. It is a poor fit if you only ever run one project, because the persistence and grouping machinery earns nothing there, and the built-in editor and web preview are conveniences rather than replacements for a real editor. Before adopting it, check that your platform has an installer, since only Windows x64, Apple silicon macOS and Linux x86-64 are listed, and expect to keep a terminal for anything the task runner does not detect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yandanp/Connexio on GitHub