Share useful context between agent tasks.
Keep related work in sync without relaying every change yourself.
Get started · Evidence · Documentation · 简体中文
You update an API in one task. Another task maintains its client and still uses the old contract. ThreadMesh helps the selected tasks share that change, while the receiver keeps the decisions already made in its own conversation.
You choose the collaborators and allowed topics. The agents judge what is relevant and how to use it. Tasks may use the same agent product or different supported products.
ThreadMesh offers two separate paths:
| Path | What it adds | Current status |
|---|---|---|
| Codex desktop skill | Guidance for scoped collaboration through Codex's native task tools | Experimental plugin candidate; marketplace discovery checked, installation and existing-task loading unverified |
| Local workspace / CLI | A persistent inbox, supported harness integrations and explicitly saved checkpoints | v0.1.0-alpha.3 available from GitHub Releases; controlled live examples recorded |
The skill does not add a messaging service. If native Codex already covers your workflow, you may not need it. Improvement over native-only use has not been measured. What ThreadMesh adds →
Start with the Codex plugin and task activation guide. It covers the candidate installation, selecting a peer, choosing a shared topic and enabling the permitted direction of communication. The skill route needs no Node, MCP server or hook setup; it requires the host's native task tools.
Installing the plugin and loading it in an existing task remain unverified. The guide separates those checks from marketplace discovery and the experimental manual workflow. Controlled handoff results below used source-loaded guidance; they do not demonstrate normal plugin installation.
After activation, ask “Check ThreadMesh status” to inspect pending advice and observed results. Say “Stop ThreadMesh collaboration” in each participating task to stop both directions. These are instructions followed by the agent, not an instant control service or a way to retract messages already submitted.
For a self-contained example, install the released CLI package. It requires Node 22+, an authenticated supported Codex runtime and available model quota. The package is distributed through GitHub Releases, not the npm registry:
npm install --foreground-scripts --loglevel=info \
https://github.com/fyaic/threadmesh/releases/download/v0.1.0-alpha.3/fyaic-threadmesh-0.1.0-alpha.3.tgz
npx threadmesh try --liveThis starts two new disposable Codex sessions for a copy-editing example, using your existing configuration. The runner continues its sample receiver after delivery and checks the receiver's own edit. It does not attach existing desktop tasks. On macOS it can also select a supported desktop-bundled runtime.
Progress is visible, the run has a 300-second total limit, and failures are
reported as failures. Processes stop at the end; private results remain for
inspection. Omit --live to read instructions without calling a model.
Setup, permissions and troubleshooting →
After installing the same CLI package, choose Pi explicitly:
npx threadmesh try preferences --agent pi --live
npx threadmesh try api --agent pi --liveThese use Pi's existing configuration and quota. The packaged API example currently requires Pi; the Codex example supports copy only. Pi setup →
After installing the CLI package:
npx threadmesh preview preferencesThis uses simulated agents and the real local coordinator, with no model login
or quota required. preview api and preview quota are also available.
A preview explains the workflow; it does not prove autonomous agent behavior.
To connect your own project sessions with a persistent inbox, follow the workspace guide.
In a controlled Codex desktop case, A maintained product facts and B maintained website copy. Both already had task context. After pairing, the ordinary request went only to A: rename the product, limit the free plan to five projects and use US spelling. A chose to send the relevant change. Original B then edited its own copy, keeping its earlier button text and the paid price unchanged.
Read the actual messages, receiver diff and audit →
| Evidence | What it establishes | What it does not establish |
|---|---|---|
| Native desktop copy case | One original-task handoff, retained prior decisions, controlled busy/stop checks | Plugin installation, independent onboarding or simultaneous-input safety |
| Native API/client case | Original receiver changed its client and tests while retaining timeout/encoding decisions | A production deployment or benefit over native-only Codex |
| Installed Codex CLI example | One released-package run passed within the default limit; earlier failures retained | Existing desktop-task adoption or a general success rate |
These are maintainer-operated examples. Delivery alone is not success: the receiver's actual work must preserve both the new requirement and its earlier constraints. The evidence index and compatibility record include narrower checks, failures and unverified paths.
| Integration | Entry and boundary |
|---|---|
| Codex desktop | Optional skill over native task tools; availability depends on the host |
| Codex CLI / projects | App Server sample pair; scoped MCP and hooks for project sessions |
| Pi | Native extension; optional idle wake with a busy-turn guard |
| Kimi Code | Project MCP integration; no automatic idle follow-up |
| DeepSeek Harness | Native MCP integration checked without a model; live initiative unverified |
| Other harnesses | MCP or JavaScript SDK integration requires host-specific setup |
Support is versioned and evidence varies by path. Consult the full support matrix before choosing an integration.
In an already configured workspace, a checkpoint can preserve selected goals, decisions, constraints and next steps for a new session:
npx threadmesh status
npx threadmesh continue backend --agent kimi --name recoveryRun from the workspace directory, with an existing checkpoint and available quota in the destination harness. This is explicit context transfer, not a full conversation backup or file migration. Recovery from an actual quota-blocked long session remains unverified. Checkpoint guide →
The native skill follows the user's selected task, topic and send permissions. Incoming advice does not authorize a reply. It cannot enforce privacy or make an idle check and subsequent send atomic; host permissions still apply.
The workspace route shares published goals and advice, not entire private conversations. Inbox reads do not consume messages, and acceptance does not prove completion. Its inbox and mute controls are separate from the native skill. This is an experimental, same-owner local system, not a multi-tenant security boundary.
Safety model · Security policy
Reports of a confusing setup step, a missed constraint or an unwanted message are useful. Include the integration path and the first failed step; remove credentials and private conversation content. Adapter authors can start with the SDK guide.
Current maintenance focuses on clear installation guidance and honest capability descriptions. Real-project validation is paused; installation, independent first use and native-only value comparison remain open, not passed. Current status · Roadmap
Report an experience · Discuss a workflow · Contribute · Documentation