CodexLoom: a place to put Codex threads that keep working

It keeps Codex's runtime and adds the organisation

The first thing the project says it does not do is reimplement the agent runtime or duplicate thread history. CodexLoom is built on Codex, and what it adds is the layer above: a Codex thread becomes the continuing workspace of a long-running Domain Agent, and around that sit durable identity, a Profile, Team relationships, bounded coordination, human governance and governed external delivery.

An Agent in that model has a stable ID, an editable name, a Profile, a primary Thread and model configuration. The same Agent resumes its work from Codex Desktop, from Mobile, from the CodexLoom WebUI or from the CLI, with live message and status synchronisation across those surfaces.

The name is the argument. Codex provides the threads, and the weaving is the point: every thread keeps its own history and direction while responsibilities and relationships bind them into a larger structure. That framing matters because it rules out the usual design where a manager agent summarises other agents into its own context.

No agent resumes another agent's primary thread

The coordination boundary is the most concrete thing in the documentation. Other Agents collaborate through bounded Messages and Topics, and they consume explicit managed Artifact handoffs. They do not resume that Agent's primary Thread.

So cross-agent work has to be declared. A Message can be sent, queued and replied to, and the system preserves delivery state, the response relationship and the complete history, which makes the trail inspectable later rather than reconstructed from context. Files move between agents as Artifacts, not as pasted content.

Two human-facing pieces sit on top. Topics carry declared cross-domain work, and Needs You is the path for requesting an explicit decision from the Owner, which is how a long-running team avoids deciding something on its own and calling it settled.

The scale path is documented as well: start with one long-lived Agent for a continuing responsibility, and split it among more Agents only when repeated work reveals stable load, context or professional-judgment boundaries. The advice is against designing the whole organisation up front.

Lead, Internal and Interface are patterns, not types

Three roles come up constantly in this space, and this project is explicit that Lead, Internal Agent and Interface Agent are organization patterns rather than hard-coded Agent types.

They are expressed through the same primitives as everything else: Profiles, declared relationships, Messages and Conversation Memberships. An Agent that behaves as a lead in one conversation and as an interface to an external group in another is configured, not coded.

The documentation also states what is not finished. Dedicated hierarchical messaging policies and organization templates are still being modeled, so the clean role model is a plan rather than a feature. That is a fair thing for a project to say out loud, and it tells you which parts of the vocabulary you can rely on today.

The Team views follow the same separation: draggable Organization, Collaboration and Activity maps keep formal responsibility, declared cross-domain work and Message evidence distinct, while Directory remains the precise view of every Agent.

Three gateways and two Go dependencies

External collaborators work through governed Interface Agents in environments they already use: Feishu (Lark), Slack and Parall. The WebUI manages external identities, Conversation Memberships, an Inbox and an Outbox for each, with the Interface Agent acting as the explicit organisational boundary rather than the domain agent answering strangers directly.

The Go module is remarkably small for that feature set. It has exactly two direct dependencies: the Lark OpenAPI SDK at v3.9.9, and zalando/go-keyring at v0.2.8. The second one is the storage decision: credentials go to the operating system's keyring rather than a file in the working directory. The indirect list confirms that spread, with dbus and godbus for Linux, wincred for Windows, gorilla/websocket for the realtime transports and protobuf.

Slack and Parall have no SDK in the module at all, so those gateways are built on the standard library and websockets. That is a deliberate choice with a cost: the Lark integration gets a maintained client and the other two do not.

The build pins pnpm exactly and embeds the frontend

The Makefile is where the engineering discipline shows. The check-pnpm target does not merely check that pnpm exists; it compares the installed version against the one declared in web/package.json and exits with an error naming both the required and the found version. So a contributor with a slightly different pnpm is stopped at the first target rather than producing a subtly different bundle.

The web target installs with --frozen-lockfile and builds the React console into internal/webui/dist, which Go embeds at compile time. The binaries target depends on web, and the comment explains why the order matters: reversing it publishes a binary that keeps serving the previous frontend after a restart.

Seven binaries come out: codex-loom, codex-loom-reloader, loom, loom-gateway, and one gateway each for Feishu, Slack and Parall, after which codex-loom is copied to codex-hub and the reloader to codex-hub-reloader. Build metadata is injected with ldflags into internal/buildinfo: the version, the twelve-character git commit with a -dirty suffix when the tree is not clean, and a UTC timestamp. The default version is 0.1.0-dev.

Local first, on port 4870

CodexLoom is local-first and self-hosted. The prerequisites are the codex CLI and a ChatGPT sign-in, and starting from source is two commands:

make release
./bin/codex-loom

The WebUI then serves at http://localhost:4870. The documented path for a first agent is short on purpose: select New agent, give it a stable name and the working directory it needs, open its workspace and send one real assignment from the responsibility it will keep owning, then use Profile in the Agent Inspector to record the smallest useful Identity, Domain and Scope.

The instruction is to refine those fields after observing real work rather than designing a complete organisation up front, which is consistent with how the rest of the document argues.

The CLI covers the same ground:

./bin/loom agent create research --cwd /path/to/repo
./bin/loom profile set research \
  --identity "Long-term researcher for this domain" \
  --domain "Continuously research the relevant products, protocols, and implementations" \
  --scope "Answer domain questions, preserve conclusions, and advise related agents"
./bin/loom thread send research "Establish a baseline for the current state of this domain"

One Owner, and a canonical Chinese document

The audience section is unusually blunt about scale. CodexLoom currently serves one advanced individual Owner first, and enterprise multi-tenant administration and general company operations are stated not to be the primary product direction. The advanced individual and one-person company case is the design target, not a stepping stone.

The documentation policy is worth knowing before you read anything else. Owner-facing product language is reviewed in Simplified Chinese first, the Chinese Owner Guide is canonical, and the English README and guide are translations that must not introduce independent product meaning. An English reader is therefore reading a derived document by design, and disagreements should be settled against the Chinese one.

The governance surface is described conservatively. Status, Daily Activity, Capacity signals and token, context, cache and model usage are available for inspection, and they are explicitly not performance scores and do not drive automatic organisation decisions. Continuous operations cover Schedules, durable external Triggers, global runtime state inspection, on-demand backups and a graceful restart that waits for active turns to finish.

The repository carries a LICENSE and a NOTICE file, AGENTS.md, and cmd/, gateway/, internal/, deploy/, skills/ and web/ directories. There are no GitHub releases, the last push to main is dated 2026-08-20, and the repository is not archived.

Editorial conclusion

CodexLoom fits one person running several agents over months on their own machine, who wants each to keep its own thread rather than hand context around. It does not fit an organisation that needs multi-tenant administration, which the README rules out as a direction. Before you plan around it, read the Chinese owner guide, since it is the canonical text and the English one is a translation, and check that your pnpm version matches the one the build requires exactly.

Frequently asked questions

Official sources

1. Issues
2. README
3. yan5xu/codexloom on GitHub