crew Lets Claude, Codex, and opencode Talk

crew is 0xmmo's small open-source CLI project that lets Claude Code, Anthropic's coding agent, Codex, OpenAI's coding agent, and opencode share live context and messages. It deals with a very plain problem: once you run more than one coding agent in the same repository, they do not naturally know what the others are editing, reviewing, or about to break. The useful takeaway is not that agents should run wild together; it is that a thin coordination layer can make parallel work and claude code review less blind.

crew is a local coordination bridge for running coding-agent sessions. It watches the sessions you already have open, injects a short summary of the others into each context, and lets one agent send a message that lands inside another agent's working context.

What crew actually wires together

The repository pitch is simple: let agents talk to each other. As of September 7, 2026, the GitHub project was small, with 22 stars, an MIT license, mostly TypeScript, and a last push on August 31, 2026. That matters because crew is not a platform announcement or a polished enterprise feature. It is a Show HN-sized experiment with one sharp idea.

The idea is to hook into the CLI agents developers already run. crew gathers each session's status, goal, recap, and a tail of recent transcript entries. Then it injects that brief context into the other running sessions, so Claude Code can see that Codex is midway through a refactor, or opencode can see that Claude Code is reviewing a test failure.

There is also a message path. The README describes crew send as a way to drop a message into another agent's context within seconds, even mid-turn. That is the part that makes the project more interesting than a dashboard. It is not just watching agents; it is giving them a mailbox.

The trap is assuming this creates correctness. It does not. A message saying another agent is editing billing/invoices.ts is coordination evidence, not a lock, a test result, or a merge guarantee.

Why the single-checkout claim got attention

The line that grabbed people was the claim that agents can ship in parallel from one checkout, without branches or worktrees. That sounds reckless if you have been burned by two humans editing the same file. It also sounds familiar if you have ever kept three terminal tabs open while asking different agents to investigate different slices of the same bug.

Worktrees are still the clean answer when isolation matters. They give each session its own filesystem view. But worktrees also add friction: branch names, duplicated setup, dependency installs, ports, databases, and a little mental bookkeeping every time you switch tabs.

crew tries a different bargain. Keep one checkout, but make each agent aware of the others' in-flight work. One agent can say it is touching the migration. Another can avoid that file and focus on frontend error handling. A reviewer session can see enough transcript tail to ask sharper questions instead of replaying the whole conversation.

That is why developers cared. The project attacks the boring coordination tax around parallel agent work, not the glamorous model-performance question.

The fair objection: most people do not mix agents

One reasonable objection from the discussion was that many developers do not actually run Claude Code, Codex, and opencode side by side. If someone lives in Codex, they tend to ask Codex to do everything. If someone lives in Claude Code, they usually stay there too.

That is true. crew is not compelling because every developer needs three agents. It is compelling because the moment you do run multiple sessions, even inside one product, the missing primitive is awareness. Claude Code has its own documented surfaces for getting started and extending behavior with skills, but local peer awareness across active CLI sessions is a different shape of problem.

Another objection is that MCP already lets agents talk to tools. That is also true, and it is a useful distinction. MCP is for connecting an agent to external systems such as GitHub, databases, document stores, or internal services. crew is about nearby agent sessions seeing and messaging each other while they work.

The trap is turning every integration into the same abstraction. A GitHub issue, a build log, and another half-finished agent session are not the same kind of context.

Try it when coordination is the bottleneck

The best first use is not autonomous feature shipping. It is a narrow parallel workflow where the agents can harm each other only a little, and where the coordination benefit is obvious.

A good example is a same-checkout review pass. Put Claude Code on implementation, put another session on tests or docs, and keep a third session as the reviewer. The reviewer can use crew's live context to see what changed, what is still being edited, and what deserves a closer diff before leaving a claude code review note.

For Claude Code users, this fits best beside normal repository conventions, not instead of them. Keep durable rules in the repo where the agent will always see them. Use a concise review convention: tests run, files touched, risks, unresolved questions. If you already use the related training topic, crew is the live side-channel, not the place to store long-term rules.

A concrete slash-command shape could be this:

/review-current-work
Check crew status first.
List active sessions touching this area.
Review only committed diffs and files the other sessions say are stable.
Return: risks, tests to run, files to re-check, and one suggested message to send back through crew.

That command is intentionally boring. It makes the agent look before reviewing. The trap is letting the reviewer treat transcript summaries as ground truth. The diff, test output, and current filesystem still win.

A safe first experiment

Copy this as a small experiment, not a grand process. The goal is to learn whether crew reduces confusion in your repo before trusting it near risky changes.

A safe command rhythm looks like this:

# Inspect active sessions before assigning parallel work.
crew

# Use machine-readable status if you want another script or agent to consume it.
crew --json

# Send a short coordination note to another active session.
crew send <session> 'I am editing tests only. Please avoid src/billing until I finish.'

The important rule is to keep crew messages about current coordination. Do not use them for architecture policy, security exceptions, or permanent repo instructions. Those belong in reviewed files and normal docs.

This is also where a lightweight review checklist helps:

Before trusting another agent's work:
- Check crew status for overlapping files.
- Run git status and inspect unstaged changes.
- Read the actual diff, not only the transcript recap.
- Run the narrow test command for the touched area.
- Send one crew message if another session should stop, wait, or re-check.

The checklist is small on purpose. If it gets much longer, you probably want a worktree, a branch, or a human pairing session instead.

Common questions

• Can crew replace worktrees?

  No, crew should not be treated as a worktree replacement when isolation matters. It gives live awareness and messaging, while a worktree gives each agent a separate filesystem state. Use crew for low-risk coordination in one checkout; use worktrees when concurrent edits could corrupt local state or confuse test results.

• How would you use crew for claude code review?

  Use crew to make the reviewer session aware of nearby agent work before it reads the diff. A practical claude code review pass should still check git diff, test output, and files touched. crew adds context such as who is editing what, not proof that the change is correct.

• Is crew just MCP for agents?

  No, crew and MCP solve different problems. MCP connects agents to external systems and capabilities, such as repositories, services, or knowledge stores. crew connects running local agent sessions to each other by sharing status, recaps, transcript tails, and messages. They can complement each other, but one does not replace the other.

• What can go wrong?

  The main risk is false confidence. A session summary can be stale, incomplete, or misunderstood by another agent. The second risk is file contention, especially in generated code, migrations, lockfiles, and shared configuration. Keep the first experiment narrow, reversible, and easy to inspect with standard Git commands.

• Does this matter if I only use Claude Code?

  It can still matter if you run multiple Claude Code sessions, but the value is smaller if you normally keep one session open. The project is most interesting when separate agents or separate sessions are working near each other. If your workflow is linear, native Claude Code features and clear prompts may be enough.

Best ways to use this research

• Best for: judging whether a live agent-to-agent context layer is useful in your current Claude Code workflow, especially when more than one session is active in the same checkout.
• Best first artifact: the safe experiment checklist above. It is small enough to try once and strict enough to catch the common failure mode: trusting a recap instead of the diff.
• Best comparison angle: compare crew with worktrees, not with model quality. The practical question is whether awareness is enough, or whether your task needs filesystem isolation.
• Best related lesson: small context surfaces beat giant memory dumps. Spotify's Portal work on cutting Claude tokens by 90% is a useful nearby example: Spotify Portal Cut Claude Tokens 90%.

Further reading

• Claude Code — getting started
• Claude Code — skills
• crew — source

Next step

Try crew on one reversible task with two sessions: one implementer, one reviewer. If the messages reduce confusion without replacing your diff review, it earned a place in your toolbox.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.