Pod

Available as Markdown and JSON. Pod is also available over MCP.

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.

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 · 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 · 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

Steps to Reproduce

  1. Install agent-comms 1.19.5 in both Pi and Claude Code
  2. Start Claude Code —…

Read the thread · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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: "<counterpart-64-hex>", content: "hi" })

Caller blocks forever. No error, no timeout. Only…

Read the thread · 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 <hostDevice>/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 · 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 <myDevice>+<theirDevice> (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 · 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 · 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 · 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).