Codux: a worktree-first control plane for nine AI coding CLIs

Not an editor, a control plane

The positioning sentence is worth quoting because it rules out a category. Codux is not another editor; it is the control plane for developers who live in AI coding CLIs and need a durable way to run multi-project, long-running agent work. The problem it names is sprawl: real work spreads across projects, Git worktrees, terminals, sessions, tokens, remote shells and context you half-remember. The answer is one native workspace built with Rust and GPUI, presented as desktop, phone and server in a single place. The roster it unifies is nine CLIs: Codex, Claude Code, Oh My Pi, OpenCode, Kiro CLI, Kimi Code, CodeWhale, MiMo Code and Agy, each of which otherwise keeps its own state and its own idea of where it is. Live agent status, token analytics, local memory and credential-isolated access sit on top of that roster rather than replacing it.

Worktree-first, because parallel tasks collide

The structural decision is that a task is a worktree. Every task keeps its own terminals, its own Git state, its own files and its own AI sessions, which is the answer to the row in the README's table about parallel tasks colliding. Two things follow from that model. Resuming a long run stops being an act of memory, because live status, local history and session restore come with the worktree, and context follows each worktree rather than floating in the session where it was created. Opening a project is enough to pick all of this up, since Git worktrees, project state and per-project sessions are detected automatically rather than configured. Token accounting follows the same grain: usage is broken out by tool, model, project, worktree and day, which is the difference between a number and a black box. Memory covers the rest, holding habits, project profiles and module notes that get injected back into supported CLIs automatically.

Credentials stay in the wrapper process

This is the part of the README that argues hardest, and the reasoning is about how credentials actually leak. Agents constantly need servers and databases, and pasting a password into a prompt or letting the model read your config files is exactly the failure mode. So Codux stores connection profiles locally and hands the agent two commands instead. codux-ssh is the first: the agent runs codux-ssh list, sees profile names and hosts only, and connects through the wrapper, while passwords and keys are injected inside Codux's helper process and never enter the model's context, the transcript or your shell history. codux-db does the same for MySQL, PostgreSQL and SQLite, where a profile is saved once in Codux and queried by name, and read-only profiles are enforced inside the wrapper with a single-statement allowlist so the model cannot escalate its own access. Setup is per-machine, not per-project, because every supported CLI learns about both commands through Codux's environment directives.

Nine CLIs, three injection mechanisms, three gaps

The support table is the honest part of the page, with five columns: live status, token usage, model setting, full-access mode and environment directives. All nine tools report live status and token usage. The injection mechanism differs per tool, and the differences are specific rather than vague: Codex takes developer instructions, Claude Code and reclaude take --append-system-prompt, OpenCode and MiMo Code are handled through a managed plugin config, and Kimi Code uses a managed --agent-file while showing no full-access mode at all. Three entries admit no injection path: Kiro CLI and Agy have no confirmed non-invasive prompt channel, and CodeWhale is not injected for interactive sessions. Oh My Pi is the odd one out on status, reading it through native OSC. The governing rule explains all of it: Codux uses non-invasive wrappers and will not write project prompt files or mutate your global CLI configuration just to inject context, so for unsupported tools it still tracks sessions where it can and leaves the prompt alone.

Peers over iroh, shipped as a beta

Remote work is framed as pairing rather than remoting. Desktop, phone and a headless host all act as peers over end-to-end encrypted P2P or relay links, powered by iroh, so you can keep driving a long agent run from somewhere else. Three properties follow from that design. Codux prefers direct P2P paths and falls back to relay only when the network demands it. It is not SSH remote desktop, since you pair devices once and then connect straight into Codux. And no public IP is required, because ordinary home, office and mobile networks are enough to pair and reconnect. The caveat sits above all of it in a blockquote: connecting to a headless host ships first as a beta in this release, and the connection, pairing and host-side data flow are still under active testing, so the README asks you to expect rough edges. A WSL distribution can also be used as a native runtime, keeping files, Git, worktrees, terminals and AI sessions inside Linux.

Sixteen workspace members and three patched crates

Cargo.toml shows how much of this is a native application rather than a shell around other tools. The workspace has sixteen members: four under apps/, covering the desktop app, its runtime, an agent binary and a wrapper helper, and twelve crates/ entries for AI history, AI sessions, Git, LLM, memory, the protocol and its FFI bridge, remote transport, runtime core and live runtime, and terminal core plus PTY. Only apps/desktop is a default member, so a bare cargo invocation builds the application and not the whole tree, and the resolver is set to 2. The dev profile is tuned deliberately: debug is line-tables-only, keeping file and line information for panics and backtraces while dropping heavy variable debuginfo, and split-debuginfo is unpacked so the information stays in the object files for faster linking and a smaller binary. Three crates are patched from git rather than taken from the registry, including async-process and async-task, and a swarm-discovery crate pointed at a dux-web repository rather than an upstream release.

justfile is sh, and macOS gets a cask

Installation on macOS is one line:

brew install --cask duxweb/tap/codux

The three steps after it are open a project, start your AI CLI in the built-in terminal, and leave the desk by pairing a phone or a headless host once. Windows users and anyone without Homebrew are sent to the download page, and the mobile build is distributed from a separate Flutter repository rather than from this one. Developer commands run through a justfile that pins its shell to sh with errexit and nounset, so recipes fail loudly. The default recipe is just --list, desktop runs a shell script under tools/, agent runs cargo run for the codux-agent package, and the mobile recipe changes into apps/mobile, can configure local iOS signing, and finds a target device by piping flutter devices --machine through a Ruby one-liner that filters for a supported device on the requested platform before building or running. The repository ships four READMEs and two changelogs, in English, Chinese, Japanese and Korean.

Editorial conclusion

Codux fits a developer already running several coding agents across several projects who has lost track of which session belongs to which branch and how much the tokens cost. It does not fit someone who wants an editor, since the README says outright that it is not one, and it does not fit anyone expecting the headless-host feature to be finished, because connecting to a remote machine ships as a beta in this release with pairing and host-side data flow still under test. Before you point an agent at a database, read the codux-db description carefully rather than assuming: read-only profiles are enforced inside the wrapper with a single-statement allowlist, so the isolation has a shape you should understand rather than a blanket deny. And check which of your CLIs is in the not-injected column, because context injection is the feature that degrades first when the integration surface is incomplete.

Frequently asked questions

Official sources

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