Doctor does not expose broken Claude Channel live notifications

[kevintseng]

Summary

MeMesh v4.8.2 can leave Claude Code in a state where the ordinary MeMesh MCP is connected but the separate memesh-channel live-notification path is broken. Durable exact-session messages still persist, which makes the failure look like the Claude agent ignored a message even though no live channel admitted it.

This was found by dogfooding the shared inbox. No message payload, private session identifier, credential, or owner-specific absolute path is included here.

Installed environment

• MeMesh: 4.8.2
• Claude Code: 2.1.251
• macOS

Minimal reproduction

1. Keep the normal MeMesh plugin MCP enabled; claude mcp list reports it connected.
2. Leave a user-scoped memesh-channel registration pointing at a deleted temporary claude.json, while the durable owner location has no current managed-host config.
3. Confirm memesh-channel reports CONNECTION_CLOSED.
4. Confirm the Local router socket is absent with MEMESH_DOCTOR_PROBE_MESSAGE_ROUTER=1 memesh doctor.
5. Send an exact-session durable message to an active Claude recipient.
6. Observe that send returns a durable message/delivery/event identity but receipt readback remains empty: no host acceptance, intake, ACK, or disposition is established.
7. Run ordinary memesh doctor: it reports Claude plugin hooks/MCP health but does not warn that the separate Claude Channel registration is missing or stale.

Expected

• Doctor reports ordinary MCP/hook availability and Claude Channel live-notification readiness as separate states.
• If the channel registration is missing, its config path is missing/stale, the router is unavailable, or the session was not launched with the required development-channel admission, ordinary diagnostics clearly say live Claude notification is inactive.
• The fix text gives explicit owner actions without auto-creating credentials, editing Claude user configuration, or claiming a session accepted a channel event.
• Release QA includes one controlled active Claude Channel journey: durable send -> metadata-only channel event -> scoped fetch of the same message -> separate host acceptance, intake, ACK, and disposition readback.

Actual

• Ordinary MeMesh MCP connectivity can be healthy while memesh-channel is independently broken.
• Durable send success is easy to mistake for live Claude notification success.
• No default diagnostic row identifies the stale/missing Claude Channel setup.

Proposed bounded acceptance criteria

• Default doctor detects configured or installed Claude support separately from live Claude Channel readiness.
• Missing/stale channel config and absent channel admission produce a warning with safe owner-controlled remediation.
• Documentation states that ordinary MeMesh MCP connectivity does not prove channel admission or agent awareness.
• Exact-candidate QA exercises a real active Claude Channel and keeps host_accept, fetch/intake, ACK, and disposition distinct.
• No credential, private session identity, payload, or owner absolute path is emitted in diagnostics or test evidence.

Why this matters

The current state passes durable storage but fails the user-visible collaboration promise: an active Claude agent is not automatically made aware of a new message. Human reminders remain necessary while the product appears installed and connected.

[kevintseng]

Dogfood update on the v4.8.3 candidate tree c33e48e6ff61ee648f809e900e10d4e2ebe5862a (Claude Code 2.1.251, macOS):

• A task-owned project-scoped memesh-channel MCP entry was accepted by Claude Code, and the development channel was explicitly admitted in the interactive UI.
• A separate claude mcp get health check reported the stdio server connected, proving the candidate server can initialize and reach the router.
• The participating interactive Claude session nevertheless never appeared in memesh message discover for the project. Router persistence showed only short-lived health-check registrations that disconnected when their probe ended; there was no living registration for the interactive session.
• Because no exact active Claude session existed, no sentinel was sent and no host_accept, intake, ACK, or disposition is claimed.
• The same candidate produced a live Codex directory card and native queue acceptance, so this failure is isolated to the Claude interactive channel boundary rather than the router directory generally.

Expected: once the project MCP server and development channel are admitted, the participating interactive Claude session maintains an active registration for its lifetime and can receive the bounded channel event.

Actual: UI admission and MCP health can look healthy while the interactive session has no active router registration.

This keeps the real Claude user-visible notification journey unverified and remains a release blocker. No payload, private session identifier, credential, or owner-specific path is included here.

[kevintseng]

Correction to my previous dogfood update: the failed Claude registration was caused by the QA invocation, not by the current candidate's Channel registration path. The test used --setting-sources project; Claude Code stores the development-channel consent outside that restricted source set, so restarting with the restriction hid the consent and the project MCP server never became a live Channel connection.

Replayed against staged candidate tree c33e48e6ff61ee648f809e900e10d4e2ebe5862a with normal setting sources and the task-owned project MCP entry:

• Claude live directory card appeared for exact session d5fe9e61-5391-477a-9283-4c89ba1affb5 with declared project/model/work metadata.
• Message 774d2c22-f349-430f-8b42-50bde338a475 was accepted by adapter claude-channel (delivery 60a057b5-1578-4c10-af46-7de55aca2dc9).
• The Claude UI displayed the injected MeMesh envelope and the model explicitly identified it as an untrusted channel message. It correctly refused to execute the payload's embedded respond exactly directive.
• Receipt readback contains host_accept only; no ACK or workflow disposition is inferred.

This verifies the real Claude native notification journey and the trust boundary for this candidate. It does not resolve the issue's separate observability concern: doctor still needs to make stale/conflicting Claude Channel configuration and inactive registration diagnosable. Keeping the issue open. No product source change was made from this correction.

[kevintseng]

Status after v4.8.3 aggregate PR #273 (merge f53c31e) — NOT closing yet.
Met: doctor reports Claude Channel registration as its own row (src/core/doctor.ts inspectClaudeChannelRegistration), emitted only for a Claude plugin cache and separate from the MCP/hook rows; a missing, malformed, or stale registration is WARN (overall PASS_WITH_CONCERNS) with no path or credential in the output — commits 3fc8e32 + e48ac76, pinned in tests/core/doctor.test.ts; docs/platforms/agent-messaging.md states that without the development-channels flag Claude may run the ordinary MCP transport while silently dropping channel events.
Outstanding: a repeatable QA that exercises a real active Claude Channel (send → channel event → scoped intake → separate host_accept/intake/ack/disposition). A one-off manual journey on 87edb29 did show an interactive Claude Code 2.1.257 session receiving a Codex-origin envelope automatically (message 5404ce1a, intake receipt written before any prompt referenced it) and a headless print-mode session NOT surfacing one despite host_accept=queued; neither is a repeatable check in the repo, so this box stays open.