Codeg: A Multi-Agent Coding Workspace Built Around ACP Sessions

The problem Codeg targets: agent sessions scattered across CLIs

Anyone who runs more than one coding agent CLI ends up with the same mess. Claude Code keeps its history one way, Codex another, OpenCode a third. There is no single place to search past sessions, and no way to hand a task from one agent to another without copying context by hand. Codeg's stated goal is to fix that: it "aggregates your sessions from every supported agent CLI into one searchable workspace." The README also describes delegation, where "a main agent delegate[s] to sub-agents of other types within a single task." That second capability is the more unusual one. Most tools in this space are single-agent wrappers. Codeg positions itself as the layer above them. The audience is developers who already pay for or run several agent CLIs and want one interface, one history, and one place to review output. It is not aimed at someone who has never installed an agent CLI; the README assumes those tools exist and are configured.

How session aggregation and cross-agent delegation fit together

The README gives the architecture at a high level rather than in detail. Sessions from supported agent CLIs are pulled into one workspace that is described as searchable. A main agent can delegate to sub-agents of other types inside a single task, which implies a routing layer that knows which agents are registered and can hand work between them. The topics list includes acp, which is the Agent Client Protocol, and the README says you "can register any other ACP-compatible agent yourself." That is the extension mechanism: fifteen agents come built in, and ACP is the door for everything else. Work that the user does not want to watch runs on a to-do board, where "each task in its own branch, running unattended, waiting for your review before it lands." The branch-per-task detail matters more than it first appears. It means Codeg is doing git worktree or branch management on your behalf, and the review step is the merge gate. The README does not describe how conflicts between concurrent task branches are handled, and that is the first thing I would want to read in the full documentation at docs.codeg.app rather than in the README.

Deployment shapes: desktop, self-hosted server, Docker, and mobile clients

Codeg ships in three server-side forms: a desktop application, a standalone server, and a Docker container. On top of that the README mentions "native iOS and Android clients for when you're away from your desk." That combination is a deliberate design choice. A desktop-only tool cannot be checked from a phone, and a server-only tool is awkward for a single developer on a laptop. Codeg covers both, which suggests the intended workflow is a long-running server that the desktop and mobile clients attach to. The README does not state whether the desktop app can run without a server, or whether the mobile clients require the self-hosted server to be reachable from outside your network. Those are the questions to answer before committing, because they determine whether you need a reverse proxy, a VPN, or a hosted instance. Nothing in the supplied material describes an authentication model for the server, so treat remote exposure as something to confirm in the reference docs rather than assume.

Getting it running and what the README actually specifies

The README does not include an install command block, a docker run invocation, or a list of configuration keys. What it does provide is the documentation site, docs.codeg.app, with three top-level paths: /getting-started/, /guide/, and /reference/. Releases are tagged on GitHub, with v0.30.6 as the most recent at the time of writing, and the badge pattern in the README points at the releases page. Because the repository's primary language is Rust, the realistic installation paths are a prebuilt binary from the releases page or a container image, but the README does not name the image or the binary artefacts. I am not going to invent a command. If you want to evaluate Codeg, the getting-started page is where the actual invocation lives, and the reference section is where agent registration and any server configuration keys would be documented. The absence of this material from the README is itself a signal: the project treats the README as a landing page and the docs site as the manual.

What the release cadence tells you about operating Codeg

Three releases landed in four days: v0.30.4 on 2026-09-06, v0.30.5 on 2026-09-08, and v0.30.6 on 2026-09-09. That is a patch-per-day rhythm on a 0.30.x line, which means the project is still moving fast and is not pretending otherwise. For a self-hosted server that other people depend on, that cadence has a cost. You either pin a version and accept that you are behind, or you upgrade often and absorb the churn. The README offers no compatibility policy for the server API, the mobile clients, or the ACP registration format, so a client and server on different minor versions is an untested combination as far as the supplied material goes. The practical move is to pin a tag and read the release notes for each version you skip. The last push date, 2026-09-10, is one day after the newest release, so the repository is actively maintained rather than archived.

Where Codeg is the wrong tool

Codeg assumes you already have agent CLIs installed, authenticated, and working. It aggregates and orchestrates; it does not replace the underlying agents or supply their model access. If you use exactly one agent and never switch, the aggregation layer adds a server, a database of session history, and an upgrade treadmill for no gain. The to-do board is also a specific workflow, not a general one. Branch-per-task with a review gate suits work that can be isolated and merged later. It fits poorly with tasks that touch shared state, long-lived migrations, or anything where two concurrent branches will collide in the same files. The README does not describe conflict resolution between task branches, so if your work does not decompose cleanly into independent branches, the board will create merge work rather than remove it. Finally, the sponsor block occupies a large share of the README, and several sponsors are API relay services. That does not affect the licence or the code, but it does mean the README is partly an advertising surface, and technical detail has been pushed to the docs site as a result.

How Codeg differs from running tmux and a session logger

The obvious alternative for someone who wants several agents in one terminal is tmux plus a shell history or logging setup. The difference in approach is structural. tmux gives you panes; it has no concept of an agent, no session index, and no way to delegate from one pane to another. Codeg models agents as registered entities behind ACP, indexes their sessions so they can be searched, and can route a task from a main agent to a sub-agent of a different type. The to-do board has no tmux equivalent at all: it is a scheduling and review layer that creates a branch per task and holds the result until you approve it. The trade is control for convenience. With tmux you know exactly which process is running and where its output goes. With Codeg you are trusting a server to manage branches, sessions, and agent handoffs, and the README does not document how much of that state lives on disk versus in a database. If you need to inspect or replay an agent's exact invocation, verify that the workspace exposes it before you migrate your workflow.

Licence and what to check before adopting

Codeg is Apache-2.0. That is a permissive licence with an explicit patent grant, and it permits commercial use and modification provided you keep the notices and state changes. It is compatible with being bundled into a larger product, which matters if you plan to run the self-hosted server inside a company. This is not legal advice; if you intend to redistribute Codeg or a modified version, have your own counsel read the licence text and the NOTICE file if one exists. The maintenance cost is the release cadence, not the licence. With patches arriving every day or two on the 0.30.x line, budget for reading release notes and testing upgrades on a schedule you control. The concrete next step is to open docs.codeg.app/getting-started/, confirm the install path for your platform, then check the reference section for how agent registration works and whether the server requires authentication before you expose it beyond localhost.

Editorial conclusion

Adopt Codeg if you already run several agent CLIs and want their sessions in one searchable place, with a review gate before work lands. Do not adopt it if you need a stable, slow-moving tool: v0.30.4, v0.30.5 and v0.30.6 all shipped within four days in September 2026, and the README's sponsor block sits above most technical detail. Verify first that your preferred agent is among the fifteen built in, that it speaks ACP if it is not, and that the branch-per-task model matches how your repository handles worktrees.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xintaofei/codeg on GitHub