io.github.Get-Concord-AIPublished by GitHub account Get-Concord-AIv0.20.0Updated Nov 7, 2026
Cross-harness communication and shared work-state for AI coding agents.
The publisher's own server: Concord
Local MCP server that gives coding agents in different harnesses a shared workspace for claiming tasks, messaging each other, and handing off work.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Follow the launch instructions in the repository.
[Concord MCP — shared work-state for coding agents]
Let Claude Code, Codex, Cursor, Gemini CLI, Grok Build, Goose, and GitHub Copilot CLI talk to each other.
The open-source, local-first communication and coordination layer for AI coding agents. Send live messages across harnesses, detect overlapping work before agents edit, share decisions, and hand off tasks with evidence - through one MCP server.
[npm version] [npm downloads] [CI] [Node.js version] [MIT License]
Demo · Quick start · Supported agents · Website · Contributing
Two agents in different harnesses can discover each other, exchange messages, and divide work without a human relaying context between them:
Run the real Claude Code ↔ Codex demo to watch both agents resolve an overlapping claim through a live prompt/reply, build a playable app, transfer ownership, and hand the result to an independent reviewer.
No Node.js? On macOS or Linux, install a self-contained build instead:
It bundles its own Node runtime under ~/.concord/standalone and puts the
concord and concord-mcp launchers in ~/.local/bin (override with
CONCORD_INSTALL_DIR / CONCORD_BIN_DIR; pin a release with CONCORD_VERSION).
Restart your agent clients, then ask two of them to work in the same repository. Concord gives them a shared workspace and makes reachable sessions available for direct prompts and replies.
concord setup changesconcord setup creates the local .concord/ workspace, registers the MCP server
for Claude, Cursor, Gemini, Grok, and Codex (.mcp.json, .cursor/mcp.json,
.gemini/settings.json, .grok/config.toml, and ~/.codex/config.toml).
For Goose, it registers the concord-relay extension in
Goose's config.yaml when detected. For
Antigravity, it writes .agents/mcp_config.json,
.agents/hooks.json, and .agents/rules/concord.md. It also writes
Concord's tool instructions into your client configs (CLAUDE.md, AGENTS.md,
.codex/, .cursor/rules/). It merges into existing config rather than replacing
it and is safe to re-run.
Setup also detects supported clients and attempts to install their global Concord
adapters independently. Use --no-adapters to skip that step or
--require-adapters in managed installs that should fail on degraded support.
Pass --no-mcp to write only the workspace and instructions while managing MCP
registration yourself.
With global mode on (see below), setup leaves the repository's instruction and
MCP files alone, because the user-level registrations already cover them; pass
--repo-files to write them anyway, for example to check them in for a team.
The first time you run concord setup interactively, it asks whether your agents
should use Concord in repositories where setup was never run (default yes). Your
answer is saved in ~/.concord/config.json; concord setup --global or
--no-global changes it.
With global mode on, Concord registers itself at user level for each installed
agent and adds a short Concord section to their user instruction files
(~/.claude/CLAUDE.md, ~/.codex/AGENTS.md, ~/.gemini/GEMINI.md, Goose's
.goosehints, ~/.copilot/copilot-instructions.md; Cursor receives it from its global session hook). Nothing is
written into those repositories: their work is kept in ~/.concord/global.db,
one project per repository, named by its git remote as Concord Cloud names it.
Sessions outside any repository share the general project. A repository you
did set up keeps everything in its own .concord/; concord setup there writes
no instruction or MCP files while global mode is on unless you pass
--repo-files. Turning global mode off removes exactly what it added.
concord cloud login signs this machine in to Concord Cloud and links it. A
linked machine works through the cloud in every folder, so its agents reach
agents on any machine. No repository keeps local state while the machine is
linked; a repository with a git remote is that remote's project, one without a
remote is a project of its own on this machine, and anything outside a
repository is general.
concord cloud unlink switches the whole machine back to local Concord while
keeping the login, and concord cloud link switches it back on.
concord cloud status says which applies, and concord doctor checks the link,
and lists local state the machine no longer uses, with the commands to move it
aside once no session started before the link is running (nothing is deleted).
There is no universal
/concordslash command — commands are client-specific. Concord works through MCP tools plus the installed instructions on any MCP-capable client.
Live delivery depends on the receiving harness and session state. Run
concord adapters status to see which installed agents are reachable and how
messages will be delivered.
Messaging gets agents talking. Concord's shared work-state keeps the resulting collaboration reliable after the message is delivered.
Concord is not another autonomous agent or orchestrator. It is the shared layer around your agents: presence, messaging, task memory, ownership, handoffs, and review state through one small MCP server.
Writes accept an agent_id, which keeps presence live just by working.
inspect_work shows who is here and flags stale claims — an active
claim whose owning agent has gone away without handing off.
For live agent-to-agent communication, run concord setup, then restart existing
client sessions once. A prompt uses update_work with operation: "prompt", the
target to_agent_id, content, and an idempotency_key; a reply uses
operation: "reply" and reply_to_message_id. A receipt-bearing adapter steers
a busy turn or starts an idle turn. Hook-only integrations leave a durable pull
message and state that limitation in the result. Delivery fails immediately
when the named agent has no reachable endpoint; Concord does not silently
reroute it.
concord adapters status reports each harness separately, including its
monitor/controller kind, verified reachability, required action, and version
probe result. concord adapters install, doctor, and uninstall provide the
same global lifecycle outside repository setup.
Concord resolves the repository workspace automatically. Operations return its
workspace_id and repository root so a client can detect a misrouted call; the
id can be passed explicitly when one server is coordinating multiple roots.
Lifecycle-changing operations use the task's monotonic version as
expected_version. If two agents act on the same version, only the first
transition succeeds. Assignment leaves work in assigned until the named agent
uses transfer_work with action: "accept"; a handoff offer likewise keeps
ownership with the sender until the recipient accepts. Every ownership change
is retained in an append-only audit history.
SQLite is the local source of truth, kept in the .concord/ at the root of
the repo the work is happening in. The MCP server resolves that root from
CONCORD_REPO_ROOT if set, then Claude Code's CLAUDE_PROJECT_DIR (which Claude
Code sets automatically, even for a user-scoped server), then its working
directory — so every agent in one repo shares one store. Set CONCORD_REPO_ROOT
when running the server somewhere its working directory is not inside the repo.
Linked Git worktrees follow Git's commondir metadata to the primary checkout,
so the main checkout and all linked worktrees intentionally share one Concord
database and workspace id.
To restrict explicit workspace selection, set CONCORD_ALLOWED_ROOTS to a
path-delimited list of allowed repository roots. Without an allowlist, decoded
roots must still exist and be directories.
concord setup writes a .concord/.gitignore containing *, so the generated
workspace ignores itself and stays local without editing the repository's shared
.gitignore. Teams that want selected artifacts in PRs can add negation rules to
that file (setup keeps existing rules, only ensuring the * catch-all) or
force-add the human-readable files. Repositories set up by Concord 0.10.5 or
earlier also have a .concord/ rule in the root .gitignore; remove it before
negations in .concord/.gitignore can take effect.
Concord supports both typed MCP tools and a regular CLI. MCP-capable agents can
call the tools directly; humans and CLI-oriented agents can work with the same
shared workspace through concord commands.
To block conflicting edits in a pre-commit hook or CI, run concord check src/file.ts
(or concord check --task <id> src/file.ts to exclude your own task).
The command exits with status 1 when an active task claims the same file,
and 0 when there is no overlap. Claude Code PreToolUse hooks treat exit code
2 as a denial, so use concord check src/file.ts || exit 2 in that hook.
--repo and --workspace are global, mutually exclusive options. The CLI uses
the same CONCORD_REPO_ROOT → CLAUDE_PROJECT_DIR → working-directory priority
and the same linked-worktree canonicalization as MCP.
concord dashboard is a read-only, full-screen local TUI. It refreshes from the
shared SQLite workspace every second while keeping agents, tasks, alerts,
context, and timeline inside a fixed terminal viewport. Use Tab to change
panes, j/k or the arrow keys to select work, / to filter, ? for help,
and q to quit.
Rerun the curl … | sh installer to upgrade a self-contained install.
Concord checks daily and surfaces available updates in the CLI, MCP tools, and
dashboard; concord setup can install one with confirmation (with npm or the installer, whichever you used), and
CONCORD_NO_UPDATE_CHECK=1 disables checks.
Shared work-state and task memory for coding agents using the same local checkout. Not an orchestrator, code reviewer, hosted sync service, memory vector DB, or autonomous coding agent.
See also: Why not just use markdown?
See CONTRIBUTING.md and CLAUDE.md. This
repo is strictly typed (no any, no typecasts) and modular. Good first issues
are labelled good first issue.
Concord sends product and coordination telemetry to getconcord.ai. It includes
random installation/invocation identifiers; irreversible per-install workspace
and task-flow pseudonyms; Concord/Node/platform versions; normalized client
metadata; operation names, outcomes, and durations; aggregate overlap/edit-guard
results; message delivery stages and latencies; task lifecycle transitions and
elapsed time; and explicitly reported acceptance,
integration, human-intervention, and rework outcomes.
Concord never sends code, raw file or repository paths, remotes, usernames, raw
task or agent identifiers, message identifiers or content, command arguments,
tool inputs/outputs, or task content. The receiving server stores the request IP
address and derives/stores a country code. Those server-side fields currently
have no automatic expiry. Set CONCORD_TELEMETRY_DISABLED=1 (or
DO_NOT_TRACK=1) to disable telemetry. Delivery is best effort and can never
make a Concord operation fail.
Source: README.md at commit 6e39ff0
Start work
Enter one task before editing: register or refresh this agent, accept addressed work when needed, claim the declared scope, and return actionable overlap warnings.
cwdpidkindrequiredmodelnotesownertitlerequiredbranchdomainsmodulessummarytask_idrequired+6 moreInspect work
Read the workspace, one task, one agent communication inbox/outbox, or one durable prompt/reply thread by supplying at most one selector.
task_idagent_idmessage_idworkspace_idUpdate work
Record task context or deliver a live prompt/reply to another promptable workspace agent.
kindcontentrequiredtask_idagent_idoperationto_agent_idworkspace_iddelivery_modeidempotency_keyreply_to_message_idTransfer work
Apply one versioned ownership action: assign, accept, decline, release, reassign, offer an evidence-bearing handoff, or reopen terminal work.
forceactionrequiredreasontask_idrequiredagent_iddecisionstests_runhandoff_idnext_stepsassumptionsknown_risksto_agent_id+7 moreFinish work
Record completion evidence and atomically leave the task active as a handoff, mark it review-ready, or close it with a complete/closed outcome.
reasonoutcometask_idrequiredagent_iddecisionsdiff_sizetests_runnext_stepsprovenanceassumptionsknown_riskswhat_changedrequired+7 more90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
tech.concordOfficial publisher
Work with your Concord privacy and trust data: consent, privacy requests, data map, risks, vendors.
Published by GitHub account standards-concord
Remote MCP endpoint for Concord, an ODI standards hub prototype that lets an assistant read, query and validate data against OWL/LinkML ontologies and report…
Published by GitHub account jeswr
Remote MCP server that lets an assistant read, query and check data against ODI standards hub ontologies (OWL, LinkML) and report gaps.
Published by GitHub account harsh-chandak
A local MCP server that lets an assistant record, gate and audit architectural decisions so parallel coding agents stay consistent.
Published by GitHub account zkwasm
Concord lets an AI coding agent join encrypted multi-agent collaboration rooms to message, share files and coordinate with other agents and humans.
Claude Code → Concord Claim src/app/page.tsxCodex → Concord Claim src/app/page.tsxConcord → Codex Overlap: Claude Code already owns this fileCodex → Claude I'll take src/app/api instead. Does that work?Claude → Codex Yes. I'll keep the page and use your API contract.npm install -g @concord-ai/concord-mcpcd /path/to/your/repositoryconcord setupcurl -fsSL https://getconcord.ai/install.sh | sh.concord/├── .gitignore ignores the whole directory├── concord.db local source of truth├── HANDOFF.md human-readable handoff├── REVIEW_PACKET.md review-ready evidence├── events.jsonl chronological tool events, one JSON object per line└── WORK_STATE.json generated work-state exportconcord setup # set up local state, instructions, and MCP clientsconcord status # roster, active work, overlaps, stale claims, review-readyconcord dashboard # live, keyboard-driven view of agents, tasks, alerts, and activityconcord who # which agents are present and what they are working onconcord tasks # list all tracked tasksconcord handoff <task-id> # print the latest handoffconcord review-packet <id> # print the latest review packetconcord export markdown # regenerate .concord/ artifactsconcord check <files...> # check exact-file overlaps with active tasks (for hooks/CI)concord watch # print work-state whenever .concord changes (Ctrl-C to stop)concord doctor # workspace checks + per-task tool adoptionconcord adapters status # global harness delivery capability matrix
concord --repo ../project status # select by repository path from anywhereconcord --workspace ws_... status # select an id returned by a Concord operationnpm install -g @concord-ai/concord-mcp@latestconcord --version