Codux Is a Control Plane for AI Coding CLIs, Not an Editor

The problem Codux targets: agent state scattered across worktrees and shells

The README frames the problem as sprawl. Work moves across projects, Git worktrees, terminals, sessions, tokens, remote shells and half-remembered context, and each AI CLI keeps its own state. Codux's answer is one project-aware view across Codex, Claude Code, Oh My Pi, OpenCode, Kiro CLI, Kimi Code, CodeWhale, MiMo Code and Agy. The intended user is a developer running long agent jobs in parallel across more than one checkout, not someone who opens a single terminal and types a prompt. The project explicitly says it is not another editor. That distinction matters: Codux is a terminal and session layer that sits in front of the CLIs you already use, rather than a place where you write code. If your workflow is one repository, one agent, one sitting, the product's central abstraction (per-worktree state that follows each task) has nothing to organise.

How the wrapper and adapter layer works

Codux runs your AI CLI inside its built-in terminal and intercepts what the CLI emits. For live status it uses non-invasive wrappers and per-tool adapters; Oh My Pi is listed as reporting status via native OSC, while Claude Code and Oh My Pi receive environment directives through `--append-system-prompt`. OpenCode and MiMo Code get them through managed plugin config, Kimi Code through a managed `--agent-file`, and Codex through developer instructions. The README states that Codux does not write project prompt files or mutate your global AI CLI configuration just to inject its context. That is the design claim worth testing, because injection channels differ per tool and the support table has holes: Kiro CLI, CodeWhale and Agy are marked as not injected, with the README noting no confirmed non-invasive prompt channel for Kiro and Agy. Those three still get live status, token usage, model setting and full-access mode, but not Codux memory or the `codux-ssh` and `codux-db` runtime commands. So the headline feature set is unevenly distributed across the eleven tools, and the table is the honest place to check before assuming parity.

Credential isolation via codux-ssh and codux-db

This is the most concrete mechanism in the README. Connection profiles are stored locally in Codux. Agents do not receive passwords or keys; they receive two commands. `codux-ssh list` returns profile names and hosts only, and the agent connects through the wrapper, with passwords and keys injected inside Codux's helper process. The README claims those secrets never enter the model's context, the transcript, or your shell history. `codux-db` applies the same pattern to MySQL, PostgreSQL and SQLite, and read-only profiles are enforced inside the wrapper with a single-statement allowlist, which is meant to stop the model escalating its own access. The stated benefit is zero per-project setup: supported CLIs learn about both commands through Codux's environment directives. The limitation is implied by the support table. On Kiro CLI, CodeWhale and Agy, where directives are not injected, an agent has no automatic route to these commands, so the isolation story depends on the tool you picked.

Getting it running: Homebrew, a project, and a CLI in the built-in terminal

On macOS the README gives one install command: `brew install --cask duxweb/tap/codux`. Windows and non-Homebrew users are pointed to the Download section rather than a command. From there the quick start is three steps. Open a project, and Git worktrees, project state and per-project sessions are picked up automatically. Start your AI CLI in the built-in terminal, with `codex`, `claude` and `opencode` named as examples, and the README says the non-invasive wrapper enables live status, token tracking and memory injection with zero configuration. Then pair a phone or a headless host to take over the same running session. Beyond that, the supplied material lists no configuration keys, no file paths for the profile store, and no environment variable names, so anything about where profiles live or how to script Codux cannot be confirmed here. The project ships under GPL-3.0, and the README links a LICENSE file; if you plan to redistribute a modified build or bundle the binary, read those terms yourself rather than relying on a summary.

Where Codux is the wrong tool

Two constraints stand out. First, the remote path is beta. The README states plainly that connecting to a headless host ships first as a beta in this release, and the sentence describing the connection, pairing and host-side data flow is truncated in the material available here, so the exact guarantees are unverified. Treat phone takeover and headless hosts as features to evaluate rather than assume. Second, the wrapper model is additive. Codux sits between you and the CLI, so every tool it supports is a moving target: when Codex or Claude Code changes how it accepts a system prompt or reports status, the adapter has to follow. The release cadence visible in the material (v2.0.1 on 2026-07-15, v2.0.2 on 2026-07-16, v2.0.3 on 2026-07-21) shows active maintenance, which cuts both ways: fast fixes, but also a surface that changes often. If you want a terminal that never intercepts anything, a plain emulator plus your CLI's own session handling is the lower-risk choice.

Alternatives and the actual difference in approach

The obvious comparison is a general-purpose terminal such as WezTerm or Alacritty, or your desktop's default emulator. Those do not know what an AI CLI is. They give you panes, tabs, scrollback and, in some cases, multiplexing, and they leave session state, token accounting and credential handling entirely to the tools running inside them. Codux takes the opposite position: it maintains project-aware state (worktrees, per-project sessions, local memory, usage by tool, model, project, worktree and day) and it accepts a dependency on per-tool adapters to do so. A second comparison is the CLIs' own native features. Codex and Claude Code already persist sessions and report token usage in their own ways; Codux's value is consolidating that across tools and worktrees into one view. If you only use one CLI, the native session handling is likely sufficient and you avoid the wrapper entirely. If you use three or four and lose track of which worktree holds which running agent, the consolidation is the whole point.

Maintenance cost and what the licence implies

The material shows three releases inside a week in July 2026, and the README documents a per-tool support matrix with distinct injection mechanisms. That combination sets the maintenance expectation: expect to update Codux when your CLI updates, and expect the support table to move. There is also a platform dimension. The README lists macOS, Windows and Linux badges, and separately describes using an installed WSL distribution as a native Codux runtime so that files, Git, worktrees, terminals and AI sessions stay inside Linux. That is a real convenience for Windows developers, but it also means your environment has more layers to debug when something goes wrong. On licensing, Codux is GPL-3.0. Internal use of a desktop application is not the same question as redistributing a modified binary or shipping it inside a product, and the two are governed differently. This is not legal advice; if redistribution is part of your plan, read the LICENSE file in the repository and get your own answer.

Editorial conclusion

Adopt Codux if you already run Codex or Claude Code across several Git worktrees and want one window that keeps sessions, token counts and saved SSH and database profiles together. Do not adopt it if you only ever run one AI CLI in one checkout: the wrapper layer and the project-aware state model buy you nothing, and you take on a GPL-3.0 desktop binary plus a beta remote path. Before installing, verify two things against your own setup: that your CLI appears in the support table with the environment-directive column filled in, and that the mobile and headless-host linking, which the README labels beta, is stable enough for the sessions you intend to drive remotely.

Official sources

1. duxweb/codux on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases