Codeg review: one workspace for Claude Code, Codex and other agent CLIs

The session sprawl Codeg is built to fix

Anyone who uses more than one AI coding CLI ends up with history scattered across tools. Claude Code keeps its own transcripts, Codex keeps its own, OpenCode keeps its own, and none of them know about the others. Codeg's answer is to aggregate sessions from every supported agent CLI into one searchable workspace, per the README. The README also states that fifteen agents come built in and that any other ACP-compatible agent can be registered by the user. That second point matters more than the count: ACP is the protocol the project is built around, and the topics list confirms it. If your agent speaks ACP, Codeg can host it; if it does not, the built-in list is your only option. The target user is someone running several agents in parallel, not someone happy with one. The repository is written in Rust with a Next.js frontend, and the README lists a desktop app, a standalone server and a Docker container as deployment shapes, plus native iOS and Android clients.

How delegation and the to-do board actually work

Two mechanisms separate Codeg from a terminal multiplexer. The first is cross-agent delegation: a main agent can hand work to sub-agents of other types inside a single task. The second is the to-do board, where each task gets its own branch and runs unattended until you review it before it lands. The topics list includes worktrees, which is consistent with the branch-per-task model: the isolation is at the git level, so an unattended run cannot trample your working tree. The Dockerfile shows how delegation is wired at runtime. It builds a second binary, codeg-mcp, described in a comment as the stdio MCP companion the runtime injects per session, and the comment notes it must ship next to codeg-server so that locate_codeg_mcp_binary() finds it through an exe-sibling lookup. That is a concrete coupling: move or rename codeg-mcp and delegation breaks. The architecture is a Rust server (codeg-server) serving a statically exported Next.js frontend, with SQLite present in the runtime image, so state is local to the deployment rather than in an external database.

Installing Codeg with Docker Compose and your first task

The repository ships a docker-compose.yml. It builds from the local Dockerfile by default, with a commented line for the pre-built image xintaofei/codeg:latest, and maps port 3080. Three environment variables are set: CODEG_TOKEN, CODEG_PORT and CODEG_HOST. The compose file itself reads as follows for the service, the port mapping and the volume.

services:
  codeg:
    build: .
    # Or use a pre-built image:
    # image: xintaofei/codeg:latest
    ports:
      - "3080:3080"
    volumes:
      - codeg-data:/data
      # Mount your project directories (optional):
      # - /path/to/projects:/projects
    environment:
      - CODEG_TOKEN=${CODEG_TOKEN:-}
      - CODEG_PORT=3080
      - CODEG_HOST=0.0.0.0

Note the commented project mount: the workspace will not see your code until you uncomment it and point it at a real path. Set CODEG_TOKEN before you start the service, since the compose file passes it through from the environment and defaults to empty. Once the container is up, open the workspace, connect the agent CLIs you use, and create a task. According to the README, a task placed on the to-do board runs in its own branch and waits for your review before it lands. The README does not document a first-run wizard, so expect to configure agents yourself. For the desktop build, install.sh and install.ps1 sit at the repository root, and the README points to docs.codeg.app for the full getting-started path rather than repeating install steps.

The Docker upgrade trap and other real limits

The compose file carries an unusually candid warning. In-place upgrades through Settings, Software Update rewrite the binaries and web assets inside the container's writable layer, not the image. The codeg-data volume survives, but the upgrade lives only in the running container: recreating it with --force-recreate, or after a docker pull, starts from the image again and drops the upgrade. The stated fix is to build or pull an image at the new version and recreate. That is a genuine operational constraint, and it means the upgrade button and image-based deployment are two different workflows that do not compose. The Dockerfile shows a second sharp edge. libicu72 is installed specifically because OfficeCLI ships as a self-contained binary with an embedded .NET runtime and aborts with a missing ICU package without it; the comment warns the version is pinned to Debian bookworm and must be bumped if the base image moves. Anyone forking the Dockerfile onto a newer base inherits that breakage. A third limit is scope: Codeg orchestrates agents, it does not provide one. You still need credentials and accounts for each CLI, and the README's sponsor section makes clear that much of the surrounding ecosystem is third-party API relay services, which you would be trusting with your traffic. Finally, the README does not document rollback for a failed in-place upgrade, so treat the image tag as your rollback plan.

Codeg against a plain terminal and tmux

The obvious alternative is running each agent in its own terminal pane and managing branches by hand. That approach has no server, no token, no container, and no ICU pin to maintain. What it lacks is exactly what Codeg adds: a single searchable view across sessions, and delegation where one agent's sub-agent is a different product. If you only ever run Claude Code, tmux plus git worktrees gets you branch isolation without the rest. Codeg's value appears at the point where you want a Codex sub-agent inside a Claude Code task, or where you want to leave a task running unattended and review it later from a phone. The mobile clients are part of that pitch, and they are the part a terminal cannot replicate. Weigh the operational surface honestly: a Rust server binary, a Next.js export, a SQLite-backed volume, a companion MCP binary that must sit beside the server, and a Docker image whose in-place upgrades do not persist. That is a real amount of machinery for session aggregation.

Licence, releases and what maintenance looks like

Codeg is Apache-2.0, which permits commercial use and modification, and the LICENSE file is at the repository root. The practical licence implication is that self-hosting and forking are both allowed, but if you modify and redistribute you take on the notice and attribution obligations Apache-2.0 sets out; that is a description of the licence text, not legal advice. On maintenance, the last push was on 2026-09-10 and the most recent release listed is v0.30.6 on 2026-09-09, with v0.30.5 and v0.30.4 in the days before. The release cadence is fast and the version number is still in the 0.30 range, so expect breaking changes between minor versions and pin the image tag you deploy. The repository is not archived. The package.json version is 0.30.7, ahead of the newest listed release, which suggests the tree moves between tags. For upgrade cost, the compose file's own note is the number that matters: an in-place upgrade inside a container is ephemeral, so budget for rebuilding or pulling an image at each version you want to keep.

Editorial conclusion

Adopt Codeg if you already run several agent CLIs and want their sessions in one place, or if you need a self-hosted server the mobile clients can reach. Skip it if you use a single agent, since the aggregation layer adds a server, a token and a Docker upgrade trap for no gain. Before rolling it out, verify the CODEG_TOKEN value you intend to use and confirm which container image tag you will pin, because in-place upgrades inside a container are lost when the container is recreated.

Frequently asked questions

Official sources

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