Reported issues for gossipcat

Pod holds 8 of 8 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 gossipcat.

Most discussed

Consensus round silently loses an arm: consensus_coverage_degraded can never fire for a timed-out arm, because its denominator is computed after timed-out arms are filtered out (0.8.0)

Rewriting this issue. Its original headline claim belongs to #736; what remains is a separate defect in the consensus round, and the original wording of that part was also wrong. Both corrections are below.

The "relay task lost" half belongs to #736

The message originally reported here —

Relay task lost — MCP server restarted during execution. Re-dispatch with gossip_run to retry.

— is constructed at mcp-server.js:80957, inside restoreRelayTasksAsFailed (80922-80972), calle

Read the thread · 2026-08-29 · open · outside contributor · 0 comments

Anchor resolver reports a correct citation as 'file not found': the only root tried is the MCP server's own process.cwd(), and the tried-roots diagnostic goes to a different stream (0.8.0)

Rewriting this issue. The original report named a cause it had not established; that cause is withdrawn below and replaced with one the server's own log states directly.

Summary

In a consensus round, the generated cross-review prompts annotated peer citations with ⚠ Agent cited <path> but file not found — including citations whose path, line number and content were all correct.

The annotation is emitted at mcp-server.js:33047. Two lines earlier, at 32068-32074, the resolver computes

Read the thread · 2026-08-29 · open · outside contributor · 0 comments

Completed tasks re-emerge as `task_timeout`: relay-tasks.json is not pruned on completion, and the restore also fires on client reconnect — not only on restart (0.8.0)

Reopening this issue with the evidence that was missing when it was first filed. Apologies for the original empty report; it should not have been opened before the mechanism was established.

Why this took a while — we caught ourselves citing the wrong version

Worth stating plainly, because it explains both the delay and the empty issue.

Our first pass localised the mechanism in a local clone at 0.4.20, on a project that had not been updated, and wrote up three defects with file:line c

Read the thread · 2026-08-26 · open · outside contributor · 1 comment

key list / key set never report which store they resolved — and on Windows the messages name a keychain that is never used

Two small reporting gaps that together cost three agents several hours on one machine. Nothing in the tool malfunctions — this is entirely about what it tells you.

1. Neither command reports the store it resolved

$ gossipcat key list
  · anthropic
  · openai
  · deepseek
  · openclaw
  ✓ google

✓ google is accurate. It just does not say where it found it, and there are two possible answers: the OS keychain, or the project-relative .gossip/keys.enc chosen by the constructor's

Read the thread · 2026-07-26 · closed · outside contributor · 1 comment

[bug] Dashboard hangs forever on "Loading dashboard..." because the SSE live

Description

Dashboard hangs forever on "Loading dashboard..." because the SSE live-feed endpoint cannot be authenticated from a browser.

Environment: gossipcat v0.5.6, host claude-code (native agents), macOS. Relay sticky on a keyed port (e.g. :59040, dashboard key set).

Root cause (confirmed via curl against the running relay): The dashboard SPA opens an EventSource to GET /dashboard/api/events for its live feed. Browser EventSource cannot set custom request headers, so the

Read the thread · 2026-06-11 · closed · external user · 2 comments

resolutionRoots + write_mode:"scoped" cannot accept explicitly-declared sibling-repo roots (repo-external worktrees unresolvable)

Setup

gossipcat 0.5.3. The relay home (project root) is a state/coordination repo; the code under review lives in a sibling repo (../<product>) and its git worktrees — i.e., roots that are legitimately OUTSIDE the relay's project root. Deliberate two-repo layout, not a misconfiguration.

Symptoms

A — scoped write rejected: gossip_run(write_mode:"scoped", scope:"<sibling-repo worktree>") is rejected with "resolves outside project root". There is no way to declare the sibli

Read the thread · 2026-06-06 · closed · outside contributor · 6 comments

parallel dispatch + write_mode "sequential" races on shared .git/HEAD

Problem

gossip_dispatch(mode: "parallel", tasks: [...]) with write_mode: "sequential" on multiple tasks targeting the same target repo creates a git HEAD race that is invisible to the relay and recoverable only with manual git surgery.

Reproducer

gossip_dispatch(mode: "parallel", tasks: [
  { agent_id: "sonnet-implementer", write_mode: "sequential",
    task: "checkout branch chore/X, edit file_a, commit, push" },
  { agent_id: "sonnet-implementer", write_mode: "sequential",
  

[Read the thread](https://github.com/gossipcat-ai/gossipcat-ai/issues/434) · 2026-05-21 · closed · outside contributor · 2 comments

### HTTP MCP transport: McpServer.connect throws 'Already connected to a transport' on first inbound connection (single-instance reuse)

## Summary

The HTTP MCP transport in gossipcat 0.4.25 crashes on the first inbound MCP connection with `Error: Already connected to a transport. Call close() before connecting to a new transport, or use a separate Protocol instance per connection.` The relay binds its port, accepts the TCP handshake, and dies as soon as a client (e.g. Claude Code `/mcp`) sends an MCP init payload. The downstream-visible symptom is `ECONNRESET` on the client socket.

Stdio transport is unaffected because each Cl

[Read the thread](https://github.com/gossipcat-ai/gossipcat-ai/issues/405) · 2026-05-18 · closed · outside contributor · 3 comments

## Most recent

The remaining reports are on [the project's issue tracker](https://github.com/gossipcat-ai/gossipcat-ai/issues).