CodexLoom: turning Codex threads into a governed agent team

The problem CodexLoom claims: threads that end when the task ends

A Codex thread is a working session. When the session stops, the context lives in a transcript rather than in a continuing responsibility. CodexLoom's answer is to treat one thread as the continuing workspace of one Domain Agent, and to give that agent a stable ID, an editable name, a Profile, and a primary Thread. The README puts it plainly: CodexLoom "does not reimplement the agent runtime or duplicate thread history." It sits on top of Codex and adds the parts a session does not have by itself: durable identity, declared Team relationships, bounded coordination, human governance, and governed external delivery.

The intended user is narrow and stated: "one advanced individual Owner first." That means a person running several specialized agents over months, using the Codex app daily, who wants those agents to talk to each other and to appear inside group chats the Owner already uses. Enterprise multi-tenant administration is explicitly not the primary product direction. If you are shopping for a platform to hand to an IT department, this is the wrong shelf.

Identity, Messages, Topics and Artifacts: how coordination is bounded

The mechanism is a set of explicit objects rather than shared memory. Each Agent has a primary Thread that only that Agent resumes. Other Agents do not open it. They collaborate through Messages, which the README describes as preserving delivery state, response relationships, and complete history, and they consume managed Artifact handoffs for finished files. Cross-agent work is organized through Topics, and decisions that belong to the human are routed through a Needs You surface rather than being made by an agent.

The WebUI separates three maps: Organization, Collaboration, and Activity. Formal responsibility, declared cross-domain work, and Message evidence are kept distinct, with a Directory as the precise view of every Agent. That separation is a design opinion worth noting. It refuses to let chat volume imply authority, and it refuses to let a declared relationship imply that work actually happened. Capacity signals and token, context, cache and model usage are shown as evidence, and the README says they should not be read as performance scores or used as automatic organization decisions.

External delivery runs through Interface Agents acting as organizational boundaries, with identities, Conversation Memberships, Inbox and Outbox managed across Feishu (Lark), Slack and Parall. The go.mod file confirms the Feishu side is real code rather than a plan: github.com/larksuite/oapi-sdk-go/v3 is a direct dependency. Lead, Internal Agent and Interface Agent are described as useful patterns expressed through Profiles, relationships, Messages and Conversation Memberships, not hard-coded agent types. The README also admits the gap: dedicated hierarchical messaging policies and organization templates are "still being modeled."

Building CodexLoom from source and creating your first agent

CodexLoom is local-first and self-hosted, and the README gives one entry point: install the codex CLI, sign in with a ChatGPT account, then build and run. The Makefile shows what happens underneath. The release target builds the React console into internal/webui/dist, which Go embeds at compile time, and the Makefile warns that reversing this dependency publishes a binary that keeps serving the previous frontend after restart.

make release
./bin/codex-loom

After the binary starts, the WebUI listens on port 4870.

open http://localhost:4870

The same setup can be done from the local CLI. The README gives this exact sequence for a research agent.

./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"

The Profile command is the one to think about. The README advises recording the smallest useful Identity, Domain and Scope, and refining them after watching real work instead of designing a complete organization up front. In the WebUI the equivalent is New agent, then a stable name and working directory, then one real assignment, then Profile in the Agent Inspector. The Makefile also requires pnpm at the exact version pinned in web/package.json via the packageManager field; the check-pnpm target fails the build if the installed pnpm differs.

Where CodexLoom breaks down or is simply the wrong tool

The most concrete limitation is stated by the project itself: Lead, Internal Agent and Interface Agent are patterns expressed through existing objects, and dedicated hierarchical messaging policies and organization templates are still being modeled. If your plan depends on enforced escalation rules between agent tiers, the enforcement layer is not described as finished.

The second limitation is operational. There are no retrieved releases, so there is no packaged binary to download and no version to pin. You build from source with Go 1.25 and pnpm, and the embedded WebUI means a stale frontend is a real failure mode if the build order is changed. A source-built tool with a single Owner as the design center is not something to put behind a shared production service.

The third is scope. Enterprise multi-tenant administration and general company operations are named as outside the primary direction. If you need per-tenant isolation or an admin console for dozens of users, CodexLoom is the wrong tool regardless of how well the agent model fits. And the canonical owner-facing documentation is Simplified Chinese; the English README and guide are translations that, by the project's own rule, must not introduce independent product meaning. English-only readers are working from a derived document.

CodexLoom against plain Codex and against multi-agent frameworks

The honest alternative is Codex by itself. Codex already gives you threads, a desktop and mobile client, and the model configuration. CodexLoom adds identity that survives a session, Profiles, Team relationships, Topics, Needs You decisions, Artifacts, and gateway binaries for Feishu, Slack and Parall. If you run one agent on one task at a time and never need another agent to reach it, plain Codex is less machinery for the same work.

The other alternative is a general multi-agent orchestration framework, which typically starts from a graph or a message bus and asks you to define agents as nodes inside it. CodexLoom starts from the opposite end: an existing Codex thread is promoted into an agent, and the thread keeps its own history and direction. The README's own summary of the difference is that Codex provides the threads and CodexLoom weaves them into an agent organization. The practical consequence is that the unit of work is a continuing responsibility rather than a task in a pipeline, and the coordination primitives are Messages, Topics and Artifacts rather than arbitrary graph edges. The repository layout reflects this: cmd/ holds the server and the gateway binaries, gateway/ and internal/ hold the coordination and delivery code, and web/ holds the React console. The go.mod dependency list is short, with the Feishu SDK and a keyring library as the only direct requirements.

Maintenance, licence and what a running install costs you

The repository is not archived, and the last push was on 2026-08-20. That is roughly four weeks before this writing, so the tree is recent, but there are no retrieved releases, which means no changelog and no upgrade path documented in the README. The Makefile stamps VERSION, COMMIT and BUILT_AT into the binary through internal/buildinfo, with VERSION defaulting to 0.1.0-dev. Upgrading therefore means rebuilding from source and restarting. The README mentions a graceful restart after active turns finish and a reloader binary, but it does not document rollback, so plan for keeping your own previous build.

The licence is the item to check before anything else. The repository metadata reports NOASSERTION, and the LICENSE and NOTICE files exist at the top level but their terms are not reproduced in the README. Do not assume permissive terms. Read LICENSE and NOTICE yourself, and if the terms matter to your organization, that reading is the first task, not the last. Operational cost is otherwise the cost of running a Codex client plus a local server on port 4870, with the Feishu, Slack and Parall gateways as separate binaries you start only if you need external delivery.

Editorial conclusion

Adopt CodexLoom if you are one advanced Owner already living in Codex, you run several responsibilities that should keep their own history, and you accept a build-from-source tool whose owner-facing product language is written in Simplified Chinese first. Do not adopt it if you need multi-tenant administration, general company operations, or a packaged binary with a support contract; the README states those are not the primary direction. Before committing, verify four things: that your pnpm version matches the packageManager field in web/package.json, that go 1.25 builds the tree on your machine, that the codex CLI is installed and signed in with a ChatGPT account, and that you are comfortable with a licence you must read yourself, since the repository carries NOASSERTION rather than a named licence.

Frequently asked questions

Official sources

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