One unreachable MCP server can stop PicoClaw’s agent loop

sipeed/picoclaw issue #3269 is the inspected primary source: “[BUG]If the MCP server connection fails, the agent loop will hang, causing the Picoclaw chat interface to stop replying to users..” Issue #3269 reproduces on an Android build from nightly commit 2cf030d2 with Go 1.25.11 and Qwen3. The operator configures an unreachable MCP server, restarts through PicoClaw Launcher, then observes that web chat no longer receives replies. The report identifies the control path directly: AgentLoop.Run calls ensureMCPInitialized and returns the error, ending the loop rather than isolating or degrading the failed extension. Issue #3276 describes a different ownership mismatch on Ubuntu: Launcher assumes it starts and stops the gateway itself, while systemd already owns a process bound to the port. Host overrides can also point the WebSocket proxy away from a loopback-bound gateway, and a newer launcher can write a channel type that an older gateway treats as fatal even when disabled. PR #3270 adds DashScope text-to-speech and WeChat audio delivery, showing the channel surface expanding while lifecycle isolation remains unsettled.

The facts

- sipeed/picoclaw issue #3269 was created 2026-07-20T02:54:18Z and updated 2026-07-27T16:32:24Z; state is open. - sipeed/picoclaw returned 29738 GitHub stars, 60 open issues, default branch main, and last push 2026-07-23T18:29:33Z. - Latest tagged-release baseline checked: nightly published 2026-07-02T01:26:53Z. - Issue #3269 reproduces on an Android build from nightly commit 2cf030d2 with Go 1.25.11 and Qwen3. - The operator configures an unreachable MCP server, restarts through PicoClaw Launcher, then observes that web chat no longer receives replies. - The report identifies the control path directly: AgentLoop.Run calls ensureMCPInitialized and returns the error, ending the loop rather than isolating or degrading the failed extension. - Issue #3276 describes a different ownership mismatch on Ubuntu: Launcher assumes it starts and stops the gateway itself, while systemd already owns a process bound to the port. - Host overrides can also point the WebSocket proxy away from a loopback-bound gateway, and a newer launcher can write a channel type that an older gateway treats as fatal even when disabled.

What changed

Issue #3269 reproduces on an Android build from nightly commit 2cf030d2 with Go 1.25.11 and Qwen3. The operator configures an unreachable MCP server, restarts through PicoClaw Launcher, then observes that web chat no longer receives replies. The report identifies the control path directly: AgentLoop.Run calls ensureMCPInitialized and returns the error, ending the loop rather than isolating or degrading the failed extension. Issue #3276 describes a different ownership mismatch on Ubuntu: Launcher assumes it starts and stops the gateway itself, while systemd already owns a process bound to the port. Host overrides can also point the WebSocket proxy away from a loopback-bound gateway, and a newer launcher can write a channel type that an older gateway treats as fatal even when disabled. PR #3270 adds DashScope text-to-speech and WeChat audio delivery, showing the channel surface expanding while lifecycle isolation remains unsettled. The primary record was inspected with its timestamps, state, body and adjacent project records. ClawCharts supplied the assignment list; it does not establish the claim.

Why it matters

MCP is an extension boundary, not the agent’s heartbeat. A failed optional server should be visible and bounded, but it should not silently end the message loop unless policy marks that server mandatory. Deployment ownership matters for the same reason: two supervisors cannot both believe they own one gateway process. The useful boundary is where persisted state, visible control and runtime behavior are expected to agree.

Current

All three records were open. The main report names a nightly commit rather than stable v0.3.1, so this is current mainline and deployment risk, not a defect proven in the stable tag. ClawCharts showed only two commits and one contributor over seven days, which makes source inspection more useful than activity volume. Repository metadata, current issues and pull requests, release baseline, Hacker News discovery and the rendered ranking row were checked. Weak search residue and historically used source spines were not promoted.

Evidence

The primary URL is https://github.com/sipeed/picoclaw/issues/3269. Supporting links are inspected current project records that establish implementation, adjacent direction or boundary conditions. Dates, reproductions, test totals and deployment observations remain attributed to their authors unless this brief explicitly says they were independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. Closure can reflect a documentation decision or triage outcome; it is not silently translated into a shipped code fix. Ranking explains why the project was scanned; it does not prove correctness, adoption or package behavior.

Operator take

Classify MCP endpoints as required or optional, apply bounded connect deadlines and expose per-server degraded state. Keep the core message loop alive when optional initialization fails. In packaged deployments, choose one supervisor, detect externally managed gateways, and refuse version-skewed configuration writes that an older service cannot parse. Preserve a before-state receipt and verify the narrowest invariant where state changes. Do not broaden permissions or delete state merely because the visible symptom is inconvenient.

Caveat

Public project records are mutable. Source state was captured at publication time, and later revisions may change status, scope or evidence. No source here authorizes automatic mutation of a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.