Reported issues for Concord MCP
Pod holds 17 of 25 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to Concord MCP.
Most discussed
feat: idle monitor integrations — PreToolUse hook, concord watch, MCP resource notifications
Summary
Enforcement is currently instruction-based ("may be skipped"), and there is no way for an agent to react to another agent's Concord activity while its own session sits idle. We should ship first-class integrations that (a) enforce the workflow automatically and (b) push work-state changes.
Baseline reality: neither Claude Code nor Codex has a true always-on listener that reacts while a session is idle at a prompt — both are turn-based, and MCP has no mechanism to wake a sleeping
Read the thread · 2026-07-21 · closed · 3 comments
Reaching an idle agent: transports beyond the pull relay
0.7.0 ships a pull transport: the recipient drains its own inbox from inside its session. That works, but it leaves one real gap and a few avenues worth exploring properly.
The gap
A Codex session sitting idle at the prompt cannot be reached. Its hooks only fire during a turn, and it has no equivalent of the Claude Code plugin monitor. Concord is honest about this — update_work tells the sender the message will not be seen until the recipient's next turn — but honest is not the same a
Read the thread · 2026-08-06 · closed · 1 comment
feat: add agent retirement and stale-roster cleanup lifecycle
Problem
Agent session records accumulate indefinitely, so the dashboard's Who's here roster gradually becomes a history list rather than a useful view of the current workspace.
A dogfood check on 2026-08-05 showed:
- 14 registered agent rows
- 4 live, 4 idle, and 6 away
- all 6 away agents had been gone for roughly 2.5–20.5 hours
- those 6 agents were linked only to terminal
completeorreview_readytasks - there were 8 active tasks and no stale claims, but all 14 agents still appe
Read the thread · 2026-08-05 · closed · 1 comment
feat: detect actual changed files outside accepted claim scope
Problem
Concord detects overlap from declared expected files/modules/domains, but it does not compare actual edits or the final Git diff with a task's accepted scope.
Exact-file enforcement is currently optional and client-dependent:
- Claude Code can install a
PreToolUsehook. - Codex and other clients rely on instructions.
concord checkonly checks collisions against other active tasks; it does not report that the current task edited files outside its own claim.
In an avios-cli
Read the thread · 2026-07-27 · closed · 1 comment
feat: add an optional supervisor runner to launch or wake assigned agents
Problem
Concord can expose registered agents and publish work-state changes, but it cannot start or wake an agent. MCP resource updates only reach a connected, subscribed client, and concord watch is a passive display.
An avios-cli dogfood run treated a task claim addressed to agent: "codex" as if it dispatched work. One already-running Codex session later found the task by polling; another idle Codex session never started. Presence registration alone is not an execution handle.
P
Read the thread · 2026-07-27 · closed · 1 comment
feat: add assignment, acceptance, and ownership-safe handoff lifecycle
Problem
The current handoff tool records completion evidence and changes task status, but it does not transfer work. It has no recipient, delivery state, acceptance, rejection, expiry, or ownership mutation.
During an avios-cli dogfood run, one agent created tasks using agent: "codex" and described them as handoffs to registered Codex agents. The claims had agent_id = NULL, no Codex session was started or notified, and later "reassignment" was stored only as a freeform decision up
Read the thread · 2026-07-27 · closed · 1 comment
bug: make workspace selection explicit across MCP, CLI, and Git worktrees
Problem
Concord's MCP server resolves one repository when the process starts and keeps that database open for the lifetime of the server. The CLI instead resolves the current working directory on every invocation.
This creates two observable failures:
- An agent launched from a parent or different directory can
cdinto a repository and pass that repository asregister_agent.cwd, but MCP writes still land in the startup workspace. Thecwdfield is descriptive metadata, not routing. 2
Read the thread · 2026-07-27 · closed · 1 comment
Add acknowledgment and clearing lifecycle for dashboard alerts
Problem
The dashboard's Alerts pane has no explicit alert lifecycle or user action to acknowledge, dismiss, or clear an alert.
Alerts are currently assembled in src/cli/dashboard/app.tsx from several different projections:
- overlaps: recomputed from active task claims and disappear when the underlying overlap is removed or a task is handed off
- stale claims: derived from active tasks plus agent presence and disappear after the agent returns or the task is handed off
- open question
Read the thread · 2026-07-27 · closed · 1 comment
Most recent
bug: cursor does not always start the message monitor on a new session
What happened
Cursor does not alway start the message monitor on a new session
Steps to reproduce
- Open a new cursor agent session within the IDE
- Try get another agent to message cursor
Expected behavior
Cursor to acknowledge or respond to the message
Environment
- Concord version: (
concord --version) - Client: (Claude Code / Codex / Cursor / other)
- OS + Node version:
Additional context
Most agents listen for messages using a monitor - cursor does not always star
Read the thread · 2026-08-26 · open · 0 comments
feat: add goose integration
Goal
Add first-class goose support so goose agents can participate in Concord workspaces and coordinate with agents running in other harnesses.
Goose is extensible through MCP, making it a good fit for Concord's cross-harness model.
Scope
- Detect goose during
concord setup. - Configure Concord through goose's supported MCP/extension configuration while preserving unrelated extensions and settings.
- Add Concord workflow instructions using goose's supported configuration/instruction
Read the thread · 2026-08-25 · open · 0 comments
feat: add Kiro integration
Goal
Add first-class Kiro support so Kiro agents can join Concord workspaces and communicate with agents in other supported harnesses.
Kiro supports MCP-based tooling, so Concord should integrate through the native MCP path and preserve Kiro's existing configuration.
Scope
- Detect Kiro during
concord setup. - Register Concord in the appropriate project/user MCP configuration without replacing unrelated settings.
- Add Concord workflow instructions through Kiro's supported steering/i
Read the thread · 2026-08-25 · open · 0 comments
feat: add Roo Code integration
Goal
Add first-class Roo Code support so Roo agents can participate in Concord alongside agents in other harnesses.
Roo Code supports MCP servers and custom modes/instructions, so the integration should use native configuration rather than a wrapper.
Scope
- Detect Roo Code during
concord setup. - Add a repository-scoped Concord MCP configuration while preserving existing Roo MCP servers/settings.
- Add Concord workflow guidance through Roo's supported instruction/custom-mode mechani
Read the thread · 2026-08-25 · open · 0 comments
feat: add Cline integration
Goal
Add first-class Cline support so Cline agents can join Concord workspaces and coordinate with agents running in other harnesses.
Cline supports MCP servers, so baseline Concord support should use the native MCP path rather than a wrapper.
Scope
- Detect Cline during
concord setup. - Configure a repository-scoped Concord MCP server using Cline's supported MCP settings while preserving unrelated servers/settings.
- Add Concord workflow instructions through Cline's supported rules/
Read the thread · 2026-08-25 · open · 0 comments
feat: add GitHub Copilot CLI integration
Goal
Add first-class GitHub Copilot CLI support so Copilot agents can join the same Concord workspace and communicate with agents in other harnesses.
GitHub Copilot CLI supports MCP servers, making it a natural Concord integration target.
Scope
- Detect Copilot CLI during
concord setup. - Register Concord using Copilot CLI's supported MCP configuration without replacing unrelated user settings.
- Add Concord workflow instructions through the harness's supported instruction/config pat
Read the thread · 2026-08-25 · open · 0 comments
feat: add auto upgrade/upgrade prompt
The problem
Concord changes regularly and mostly works in the background
Proposed solution
Concord should auto update or prompt to update similar to Codex or Claude Code
Alternatives considered
n/a
Scope check
Within scope
Read the thread · 2026-08-24 · closed · 0 comments
refactor: replace granular MCP lifecycle tools with a five-tool workflow surface
Problem
Concord currently exposes a granular lifecycle API whose distinctions are valid internally but costly and confusing for agents:
register_agent→get_work_state→claim_workis the ordinary start sequence.assign_task,reassign_task,offer_handoff,accept_task,accept_handoff,decline_handoff, andrelease_tasksplit closely related ownership operations across many tools.handoff, review-ready state, andclose_taskfragment ordinary completion.- `get_wor
Read the thread · 2026-07-30 · closed · 0 comments
bug: preserve agent metadata and separate heartbeat, activity, and reported status
Problem
Agent presence currently conflates several different concepts:
- write operations only touch
last_seen; - an agent marked
donecan becomelive/donewhile actively doing new work; - status/summary can remain stale while writes keep the agent live;
- repeated
register_agentcalls are full replacement upserts, so omitted optional fields overwrite existing cwd, worktree, owner, model, or PID withNULL; - active claims with
agent_id = NULLare intentionally skipped by stale-c
Read the thread · 2026-07-27 · open · 0 comments
The remaining reports are on the project's issue tracker.