Meldwork and the problem of copying context between agent terminals

One frozen task snapshot, several CLIs, one review

Meldwork is a local-first multi-agent orchestration desktop app for macOS on Apple silicon, and it starts from a situation most people running coding agents recognise. You have several agent command line tools installed, and each of them wants context. Moving a task from one to the next means copying the prompt, the file references and the findings by hand, and nothing records what was actually said.

The mechanism Meldwork uses to break that is the frozen task snapshot. The README describes it as freezing one task snapshot, sending it to every selected agent, capturing their independent findings as evidence, and gating workspace writes behind approval. Nothing is invented here, no agent framework is imposed, and no model is hosted. The app connects the CLIs you already have: Codex, Claude Code, Hermes, OpenCode, Gemini CLI, Qwen Code, Kimi Code, MiMo Code, Pi Agent, OpenClaw, OpenCodeReview and WorkBuddy. The project calls it heterogeneous CLI support, and the description is that you keep your own tools and credentials and gain coordination on top.

The workflow is four steps. You select the local agents and participants, you scope the goal, working directory, context and permissions, you run one of the collaboration modes, and then you review and adopt the result, the evidence and any Human Gate before changing the workspace. The scoping step is where the safety model lives, because the working directory and permissions are declared before an agent runs rather than inferred after it.

Who this is for is stated plainly: people who run multiple agent CLIs and want independent review for code, research or product analysis, and people who need inspectable traces so that work can be resumed, audited and reused across sessions. It is a review desk for agents, not a replacement for them.

The evidence chain from Finding to Disposition

The structural difference between Meldwork and a terminal multiplexer is what happens to the output. The README contrasts itself with tools like tmux and zellij, which show raw output side by side, and says Meldwork preserves every finding as structured evidence in the chain Finding, then Evidence, then Decision, then Disposition.

That chain is a small idea with large consequences. A raw terminal scroll tells you what an agent printed, which mixes the assertion, the supporting observation, the choice and the outcome into one stream. Splitting them means a reader can look at a decision and ask what it rested on, and a reader can look at a disposition and ask which decision it belongs to. That is the difference between a transcript and an audit trail, and it is the reason the same output can be reused in a later session instead of being re-derived.

The other half of the model is the human adoption gate. Writes to the workspace are not applied on the agent's say-so; the result, the evidence and the gate are reviewed before the workspace changes. For an agent that edits files, that inverts the usual default of a coding CLI, where the edit is the output and you review the diff afterwards.

The evidence structure is also what makes comparison possible. When several agents answer the same task, each answer is captured as its own findings with its own evidence, so the disagreements between them are visible as differences in the chain rather than as two wall-of-text replies side by side.

The cost of this design is that Meldwork is opinionated about workflow. It is described as a local-first multi-agent orchestration desktop app, explicitly not a terminal multiplexer, not a cloud agent fleet, not a communication network and not a programmable orchestration framework. If you want to script the agents instead of reviewing them, this is the wrong shape of tool.

Three collaboration modes, and what Direct preserves

The three modes differ in how much structure they impose, and the table in the README is worth reading closely because each mode answers a different question.

Direct runs one selected agent and keeps its conversation and its native session when supported. The point is that nothing about the agent's own state is lost, which matters for agents with their own session concept rather than being a pure request/response tool.

Concurrent Responses sends the same frozen task snapshot to the selected agents and returns independent replies in stable order. The order is stable because the comparison is meant to be read as a comparison, and the value is that you get several independent attempts at one question rather than a debate.

Auto Discussion V4 is the multi-round mode. The first round runs concurrent proposals, and later turns follow the discussion: one agent can route the next turn by addressing another with @Agent, or several agents can be selected for a concurrent response. Native agent sessions continue across rounds, so the agents keep their state while the discussion proceeds. The mode description names what it is for, which is work that benefits from discussion, flexible routing and review.

One boundary is stated and worth repeating, because it is the kind of thing that gets discovered late. Participants are always selected by the user, and automatic selection from a larger roster is outside the current preview. If your plan is to point the app at twenty installed CLIs and let it decide which to involve, that is not what the current build does.

Installing on Apple silicon, and where the code lives

Distribution is a desktop application rather than a package you install with a package manager. The README links a download for Meldwork V1.0.6 for Apple silicon macOS, which is a disk image:

https://github.com/Ryder-Sun/Meldwork/releases/download/Meldwork-V1.0.6/Meldwork-0.1.6-arm64.dmg

Two details in that file name are worth pausing on. It is an arm64 build, so it is Apple silicon only, which matches the stated platform support of macOS on Apple silicon. And the release is tagged Meldwork-V1.0.6 while the file itself is named Meldwork-0.1.6-arm64.dmg, a mismatch between the tag number and the packaged version that will trip up any script that derives a version from either one.

The repository layout is a three part Electron application. The desktop/ directory holds the desktop shell, frontend/ is the web layer, and meldwork-landing/ is a separate landing site. There is also a meldwork-landing directory alongside docs/, and top level files that describe the project in detail: architecture.md, AGENTS.md, CHANGELOG.md, SECURITY.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md.

The agent discovery behaviour is visible in the screenshots the README links, one of which shows local agent detection. The described model is that Meldwork finds the CLIs already installed on the machine rather than bundling or installing them, which is why the app is a coordinator and not a distribution channel for models or agents.

The project page is hosted at ryder-sun.github.io/Meldwork, and the README also links a Chinese version, README.zh-CN.md, alongside the English one, so the documentation is bilingual at the top level.

Where Meldwork sits against tmux and against frameworks

The README includes a comparison table, and the honest reading of it is that Meldwork is choosing a position rather than covering the whole field.

Against a terminal multiplexer such as tmux or zellij, the difference is what the output becomes. A multiplexer gives you panes, and the work of passing context between agents stays manual. Meldwork gives you a frozen snapshot sent to every selected agent, an evidence trail, a human adoption gate, and no manual context passing. If you are happy to copy and paste, the multiplexer is lighter and has no opinions.

Against programmable frameworks that you build yourself, the difference is that nothing has to be written. Meldwork is a ready to use desktop workflow with the orchestration encoded in the modes, and the cost of that is that the orchestration is not yours to change. There is no code to write, and equally no hook for writing your own orchestration.

Against parallel agent runners that isolate work in git worktrees, the README's claim is that those give parallel execution while Meldwork gives evidence backed review, with the Finding to Disposition chain rather than just parallel output. That distinction only matters if review is the bottleneck in your work rather than execution.

The comparison is against a wide field of tools, and the row for cloud hosted agent execution platforms is the clearest boundary: Meldwork runs locally in your own work cell with the CLIs you already have, with no cloud dependency. For a team that needs its agent runs to happen on infrastructure it controls, that is the deciding constraint.

Preview limits and the single platform constraint

The hard constraint is the platform. Meldwork is a macOS application for Apple silicon, and there is no Windows or Linux build mentioned anywhere in the README. For a developer whose agent CLIs live on a Linux workstation or a Windows laptop, that ends the evaluation before it starts, and it is a stronger constraint than any feature comparison in the table.

The second constraint is the one the project states about itself, which is that participant selection is manual and automatic selection from a larger roster is outside the current preview. In practice that means each run starts with you naming the agents involved, and the value of the frozen snapshot across twelve possible CLIs depends on you knowing which ones you want in the room.

Other limits are quieter. The README describes Direct mode as keeping a native session when supported, which is a conditional promise across twelve different CLIs, each with its own session model. The multimodal capability is demonstrated for Direct work with local files and media, but the documentation does not say which other modes accept attachments. There is no CLI, no API and no headless mode described, so every run is a person at the app, and the project does not describe a way to script the workflow.

The security posture is asserted rather than documented in the excerpt available here. A SECURITY.md exists in the repository, and the permissions scoping step is real, but the README does not state what the app writes outside the workspace directory, how scoped permissions are enforced against a CLI that has its own tool permissions, or what happens to a recorded session when you delete it. Those are the questions to answer with the source before trusting it with a repository that matters.

Apache-2.0, a commercial use file, and a young release line

Meldwork is licensed under Apache-2.0, with the licence text in the LICENSE file and third-party notices in NOTICE. The repository also ships COMMERCIAL_USE.md alongside them, and this is the part an organisation should read before deploying it, because a permissive licence on the code does not by itself describe what the surrounding terms are for a commercial product. That is a document to read and a question for your own counsel, not a conclusion from this page.

On the release side, the project tags releases and publishes them. Meldwork-V1.0.4 was published on 2026-09-01, Meldwork-V1.0.5 on 2026-09-17 with the name General Agent workspace prerelease, and Meldwork-V1.0.6 on 2026-10-18. The repository is not archived and the last push was on 2026-10-19, so the code is moving and the releases are recent rather than historic.

A prerelease appearing inside the 1.0 line is the detail to note, since it means the feature set described in the README, including the Auto Discussion V4 routing and the multimodal Direct work, is still arriving in pieces. Anyone depending on a specific mode should check the CHANGELOG.md file before upgrading, and the file naming mismatch between the 1.0.6 tag and the 0.1.6 disk image is the kind of small inconsistency that a new project can still fix without anyone being surprised.

Editorial conclusion

Meldwork suits a developer on an Apple silicon Mac who already drives two or more agent CLIs and wants a reviewable record of what each one said before any file changes, and it does not suit a team on Linux or Windows, on the cloud, or looking for an orchestration framework to program against. Before installing it, read COMMERCIAL_USE.md next to LICENSE, and expect to pick participants by hand, since automatic selection is outside the current preview.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Ryder-Sun/Meldwork on GitHub