# Reported issues for Agent Comms Pod holds 17 of 17 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects. Back to [Agent Comms](/mcp/agent-comms). ## Most discussed ### Bridges other than the coordinator cannot see or message agents on other machines Only the process that holds the coordinator role on a machine can see or message agents on another machine. Every other bridge on that machine, including each Claude Code session the default cc-peer front handles, gets AGENT_NOT_FOUND for a remote agent. Reproduced on 5.2.3 with two machines through mesh.exadev.io. On machine B two `bridge mcp` processes ran, p1 as coordinator and p2 as a peer, with a Claude Code session fronted by p1. Machine A ran a sender that had DM'd the fronted session.… [Read the thread](https://github.com/ExaDev/agent-comms/issues/293) · 2026-09-20 · closed · 2 comments ### Web-bridge integration tests' MeshStore becomes real coordinator and dials the production hub createWebServer() (used throughout src/bridges/user/web/test/*.integration.test.ts) constructs its ChatController with a real identity slot ({ harness: "user", cwd: process.cwd() }) and its own coordinatorPort. Confirmed directly (not guessed) with a small script constructing a handle the same way these tests do and inspecting it 3s later: coordinatorGateway.isConnected is true and transport.hub.isConnected is true -- the test server becomes the local mesh coordinator and… [Read the thread](https://github.com/ExaDev/agent-comms/issues/236) · 2026-09-19 · closed · 2 comments ### Peers on same coordinator cannot see each other — mesh state not syncing across harnesses Two agents (Pi and Claude Code) connect to the same coordinator on `localhost:19876`, both register successfully, but neither appears in the other's `list_agents`. Both see only themselves in the shared room. ## Environment - **OS:** macOS - **agent-comms version:** 1.19.5 (both sides) - **Harness A:** Pi (npm: `agent-comms@1.19.5`) - **Harness B:** Claude Code (plugin: `agent-comms@1.19.5`) ## Steps to Reproduce 1. Install agent-comms 1.19.5 in both Pi and Claude Code 2. Start Claude Code —… [Read the thread](https://github.com/ExaDev/agent-comms/issues/13) · 2026-05-28 · closed · external user · 2 comments ### Fronted session stays unreachable and errors continuously after the coordinator is killed After a coordinator process is killed on a machine that has a Claude Code session fronted by cc-peer, the replacement coordinator (a fresh bridge in the same slot) reports "agent-comms: connection is closed" over and over, about 130 lines within a couple of minutes, and the fronted session is listed but unreachable from other machines (a DM to it either fails with AGENT_NOT_FOUND or is accepted and silently queued) until the Claude session itself is restarted. A restarted coordinator with a… [Read the thread](https://github.com/ExaDev/agent-comms/issues/285) · 2026-09-20 · closed · 1 comment ### Reply from a fronted Claude session to a DM goes to its project room, not the sender When a Claude Code session fronted by cc-peer is DM'd across machines, the delivered text says to reply via the per-correspondent alias peer, but the session's own "reply to peer" goes to the sender of the message, which is the front itself. The front then posts that reply into the fronted agent's project room, so it never reaches the person who sent the DM. Repro on 5.0.5 with two machines through mesh.exadev.io: DM a fronted session "reply with only PONG". The session (auto mode) answered… [Read the thread](https://github.com/ExaDev/agent-comms/issues/284) · 2026-09-20 · closed · 1 comment ### dm reports success when the relayed send failed and was queued `dm` returns "DM sent to : " even when the relayed room.send that carries it fails. `RoomMessaging.sendDm` records the message locally and calls `sendRoomRequestToMember`, which on any non-ok outcome (or a rejection) just queues the request in `pendingRoomRequests` and returns. Nothing is surfaced to the caller. Seen in a two-machine test on 5.0.5 through mesh.exadev.io, with the recipient a Claude Code session fronted by cc-peer: three DMs came back "DM sent" after 15006… [Read the thread](https://github.com/ExaDev/agent-comms/issues/283) · 2026-09-20 · closed · 1 comment ### Legacy FRAME_VERB path filters state-mutating messages with a deny-list The legacy FRAME_VERB path in `src/core/hub-session.ts` drops a trusted sender's `state_sync` and `state_update` through the `isStateMutatingMessage` check, so anything else a trusted device sends is passed on to `onMessage`. That is a deny-list: every new `MeshMessage` variant added later is accepted from the wire by default, and someone has to remember to add it to the list if it mutates state. It should be an allow-list of the message types that are meant to arrive over this path, with… [Read the thread](https://github.com/ExaDev/agent-comms/issues/268) · 2026-09-20 · closed · 1 comment ### gateway_trust principal: true doesn't cover a person's devices: directory merge and outbound requests still need each device trusted `gateway_trust` with `principal: true` doesn't let you see or reach the trusted person's devices, so trusting someone once still doesn't work across machines. Tried on agent-comms 4.4.0 between two machines through mesh.exadev.io. Each side ran `whoami` (which now prints a `Principal:` line) and trusted the other's principal only, no device ids. `list_agents` never showed the remote agent, however long I waited. With the remote device trusted directly it showed up within seconds. The reason… [Read the thread](https://github.com/ExaDev/agent-comms/issues/266) · 2026-09-20 · closed · 1 comment ## Most recent ### fronted Claude session can't answer a DM or join request, so first contact times out A Claude session that is only fronted by the default cc-peer front (no agent-comms MCP tool of its own) can't answer a room or DM join request, so a first-contact `dm` or `join_room` to it always times out. Tried on agent-comms 4.1.6 with a real interactive Claude Code session on a second machine, fronted by `bridge cc-peer` there. From the first machine, after trusting the fronted session's device, `list_agents` shows it fine. `dm` then waits and fails with `DM access request to was… [Read the thread](https://github.com/ExaDev/agent-comms/issues/259) · 2026-09-19 · closed · 1 comment ### test:delivery drain-dm fails: a room_join_request event is drained ahead of the DM `pnpm test:delivery` fails on main at the drain-dm case: `drained[0].type` is `room_join_request` where the test expects `dm` (src/test/delivery-receipt.helper.ts, testDrainDm). It started with the change that tells an agent when a room join is waiting on its decision (c68a5e4): the consent handshake in `dmConsent` now leaves a `room_join_request` event queued for the recipient ahead of the DM, so the first drained event is no longer the DM. The other three cases (push-room, push-dm,… [Read the thread](https://github.com/ExaDev/agent-comms/issues/257) · 2026-09-19 · closed · 1 comment ### sendDm hangs forever on first contact: requestDmAccess has no timeout despite documenting one ## Summary `sendDm` hangs indefinitely on first contact. `requestDmAccess`'s documented "rejects if it refuses or **never answers**" contract is not implemented — nothing bounds the wait for a human decision. Reproduced on v4.1.0, still present on v4.1.1 (`615dc1f`, which touches no `src/`). ## Repro Two pi bridges, no prior DM history between them: ``` agent_comms({ action: "dm", target: "", content: "hi" }) ``` Caller blocks forever. No error, no timeout. Only… [Read the thread](https://github.com/ExaDev/agent-comms/issues/249) · 2026-09-19 · closed · external user · 1 comment ### join_room by the bare name list_rooms shows fails with not a valid room-path `list_rooms` shows a remote room by its bare name (for example `e2e-test`), but `join_room` with that name fails: ``` Internal error: "e2e-test" is not a valid room-path ``` Passing the full `/e2e-test` path works. Seen with agent-comms 3.34.0 joining a public room hosted by an agent on another machine through mesh.exadev.io. There is an older test in the repo reproducing a related ROOM_NOT_FOUND for addressing a room by its plain local name, so this may be the same root cause. [Read the thread](https://github.com/ExaDev/agent-comms/issues/246) · 2026-09-19 · closed · 1 comment ### dm action can't reach a device on another machine: no room:member token Tried this between two machines through mesh.exadev.io (agent-comms 3.34.0, both sides using CommsTool via createBridgeMesh). Mutual gateway trust set up, and list_agents on one side shows the other side's agent with its versions, so discovery is fine. A `dm` to that agent then fails straight away: ``` Error: No room:member token for + (NOT_MEMBER) ``` That comes from the DM send path in room-messaging.ts, which needs a room:member token for the dm path. The only thing… [Read the thread](https://github.com/ExaDev/agent-comms/issues/245) · 2026-09-19 · closed · 1 comment ### CI never runs the Playwright e2e suite ci.yml has no Playwright step, so the e2e suite (`pnpm test:e2e`) is never run on pull requests or on main. That is how most of it (35 of 53 tests) could fail on main with a teardown timeout without anyone noticing, until it was fixed in the fixture. The suite now takes about ten seconds, so running it in CI is cheap. It should run on pull requests and pushes to main, with the Playwright browser install cached, and it should be stable across repeated runs before being relied on. [Read the thread](https://github.com/ExaDev/agent-comms/issues/243) · 2026-09-19 · closed · 1 comment ### No MCP action reports the web UI's own port No `agent_comms` MCP action reports the web UI's own port. pi has this already as `comms-url` (pi/extension.ts:190), registered directly on pi's own command system rather than routed through CommsTool - so it's unavailable to Claude Code or any other MCP client, only to pi. Every other bridge (claude-code, codex, opencode) calls tryStartWebServer() the same way pi does and gets a WebServerHandle back, but nothing exposes it through the generic tool surface. Add a `web_url`/`web_port` action on… [Read the thread](https://github.com/ExaDev/agent-comms/issues/200) · 2026-09-18 · closed · 1 comment ### agent-comms crashes on launch (ENOENT): web frontend assets are built under src/ but never copied into the published dist/ ## Summary `agent-comms@1.24.0` (current `latest` on npm) crashes on **every** invocation, before doing any work. The web UI server module reads its static assets from disk at module-load time, but those files are never copied into the published package. Because the reads happen at the top level of `server.js`, the crash occurs on `import`, taking down even unrelated commands like bare `agent-comms` (setup). ## Reproduction ``` $ npm i -g agent-comms # 1.24.0 $ agent-comms ``` ```… [Read the thread](https://github.com/ExaDev/agent-comms/issues/18) · 2026-07-07 · closed · external user · 0 comments ### Pi bridge: onDelivery never fires after first session (ephemeral TLS identity diverges from persisted agentId Steps to reproduce: 1. Start Pi with agent-comms extension — first session works (reactive). 2. Restart Pi. 3. From Claude Code, send a message to the shared room. 4. Pi never wakes up. onDelivery is never called. Observed behavior: Pi only receives messages when the user explicitly asks it to poll the room (read_room). It cannot respond autonomously. Expected behavior: Pi should wake up automatically (triggerTurn: true) whenever an actionable message (room message,… [Read the thread](https://github.com/ExaDev/agent-comms/issues/14) · 2026-05-28 · closed · external user · 1 comment The remaining reports are on [the project's issue tracker](https://github.com/ExaDev/agent-comms/issues).