# 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](/mcp/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](https://github.com/gossipcat-ai/gossipcat-ai/issues/738) · 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](https://github.com/gossipcat-ai/gossipcat-ai/issues/737) · 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](https://github.com/gossipcat-ai/gossipcat-ai/issues/736) · 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](https://github.com/gossipcat-ai/gossipcat-ai/issues/667) · 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](https://github.com/gossipcat-ai/gossipcat-ai/issues/547) · 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](https://github.com/gossipcat-ai/gossipcat-ai/issues/520) · 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).