Parley connects Claude Code, Codex CLI and OpenCode 2 sessions through a local IRC channel. A developer can watch the shared conversation in a regular IRC client, contribute instructions and let the sessions exchange selected updates without manually carrying every message between terminals.
The project’s README describes three ways to use it: long-running lines, discussion tables and two-worktree builds. Each serves a different coordination problem, and support varies by coding harness.
The useful distinction is that Parley provides a shared communication layer, not a manager that assigns everyone work. Sessions retain their existing workflows, and only material explicitly promoted for sharing leaves a participant’s stream.
The repository does not provide a formal announcement timestamp. This article analyzes its published design and setup instructions, without claiming hands-on testing.
How the Local IRC Channel Works
Parley is a small Go program built with the standard library. Its live transport is an IRC server called ergo, which parley server runs locally. The developer connects an IRC client, such as Halloy or WeeChat, to 127.0.0.1:6667 using plaintext.
That address is the machine’s loopback interface. In the documented setup, the shared channel lives on the developer’s computer, with no separate hosted chat service required.
The coding agents receive messages through their harnesses’ own push mechanisms:
| Coding harness | Incoming message path | Supported Parley modes |
|---|---|---|
| Claude Code | A Claude Code channel | Lines, tables and builds |
| Codex CLI | codex queue | Lines, tables and builds |
| OpenCode 2 | The OpenCode server’s HTTP API | Lines only |
Parley does not type messages into the agents’ terminals. Each session responds by running parley send as a tool. Underneath, the stream exposes send, cursor-based read and wait operations, with the transport determining message order. A separate file adapter supports development and tests. These mechanisms are documented in the repository.
The distinction between a channel and a mirrored session matters. Seeing every shared post does not mean seeing every private conversation, tool call or intermediate thought from every agent. The README says that, in all three modes, only content a participant promotes, on the human’s say-so, leaves its stream.
That selective boundary is potentially more useful than broadcasting everything. A planning session can share a changed requirement without dumping its entire conversation into the implementation session. The tradeoff is that participants still need to choose what other sessions should know. A shared channel cannot compensate for an important update that never gets posted.
“Local” also describes the coordination transport, not where the underlying models run. Installing Parley should not be read as a promise that Claude, Codex or another configured model processes everything on the same machine.
Lines, Tables and Builds Solve Different Problems
Parley’s three modes differ in purpose and working structure. The README recommends starting with a line.
Lines Keep Independent Sessions Current
A line connects a few long-running sessions, each continuing its own job. The intended timescale can stretch across days, with the human remaining in the room.
For example, a planning session could post that a requirement has changed while an implementation session continues working. The channel gives them somewhere to exchange that update without making one session the supervisor of the other.
Lines are also the only mode that currently supports OpenCode 2. If the goal is to connect all three supported harnesses, this is the available starting point.
Tables Put Several Models Around One Question
A table brings several agent seats together to consider one question, with the human acting as chair. Those seats can use different model families.
This mode is structured around discussion, not parallel implementation. It makes sense for comparing proposed approaches or examining a design before committing to it. Multiple seats may provide different arguments, but the documentation supplies no benchmark showing that a table produces more accurate decisions.
I’d treat a table as a way to expose disagreements for inspection, not as a voting system that makes an answer reliable.
Builds Split Work Across Two Worktrees
A build connects two sessions that agree how to divide a piece of work. Each receives its own Git worktree, giving it a separate working directory.
Builds additionally require Director in the target repository. Lines and tables do not require that extra component. OpenCode is not currently supported as a build peer or table seat.
Separate worktrees keep the sessions from editing the same checkout, but they do not make their changes logically compatible. Two agents can still make conflicting assumptions about an interface or requirement. The useful role of the channel is to surface those assumptions while work is underway.
These distinctions and support limits come from Parley’s mode descriptions.
Human Authority Is Separate From Tool Permissions
Parley marks deliveries from other sessions as peer input. The project says human messages carry authority under the developer’s registered IRC nickname.
That distinction addresses a central coordination problem: another agent’s request should not silently acquire the status of a human instruction. It is a documented design boundary, not proof that a model will handle every misleading message correctly.
Lines and tables also include a breaker that stops waking sessions after a burst of posts, or after a prolonged exchange without human participation. The sessions remain stopped until the human writes again. The README does not extend that description to builds.
The breaker provides a useful intervention point for agent-to-agent chatter. It is not described as a spending cap, task timeout or limit on work a session performs internally.
Claude Code Requires a Development-Channel Override
Claude Code is the most consequential setup caveat. According to Parley’s documentation, every Claude launch needs this option:
--dangerously-load-development-channels server:parley
The flag allows the specified development channel server to load because Parley is not on Anthropic’s channel allowlist. The launch commands printed by parley line add, parley table new and parley build new include it.
The project explicitly distinguishes this override from a permission mode. Claude Code should continue asking for tool permissions as it otherwise would. Parley also does not relay permission prompts, so another participant cannot answer one through the IRC channel. These conditions are explained in the Claude Code prerequisites.
The practical consequence is that the IRC client is not a complete replacement for the agent terminal. A developer can follow shared updates in chat while still needing to return to Claude Code to approve an operation.
I would evaluate the override as permission to load an additional integration, not as a shortcut around normal approvals. The documented scope is narrower than disabling tool permissions, but it still means trusting code outside Anthropic’s channel allowlist.
Installation Has Several Moving Parts
Parley’s README provides this build-and-install sequence:
git clone https://github.com/colinsurprenant/parley
cd parley
go build -o bin/parley ./cmd/parley
sh skills/install.sh
bin/parley doctor
These commands clone the repository, compile the binary, install links to its protocol skills and check the environment. They are the project’s instructions, not commands executed for this article.
Building requires Go 1.25 or newer. The resulting bin/parley also needs to be on the PATH used by the developer’s terminals.
The skill installer links , and into and . Those are symlinks into the checkout, so the repository needs to remain in place.
Frequently Asked Questions
4 questions
1Does Parley Replace Claude Code or Codex?
No. It connects existing sessions through their supported message paths. Each harness continues doing the coding work.
