alezmad/claudemesh
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(cli): 1.32.1 — DMs to session pubkeys finally land in inbox

Browse Source 
SessionBrokerClient (daemon-side, since 1.30.0) was constructed
without a push handler and silently dropped every inbound `push` /
`inbound` frame. Header docstring claimed it handled "inbound DM
delivery for messages targeted at the session pubkey" but the
callback was never wired.

Net effect: any DM sent to a peer's session pubkey (everything
`peer list` returns now) was queued, broker-acked, marked
delivered_at on the broker, and thrown away by the recipient
daemon. inbox.db stayed at zero rows; `claudemesh inbox` reported
"no messages" no matter what arrived.

Two-session smoke surfaced this — sender outbox status=done with
broker_message_id, recipient inbox empty.

Fix: wire SessionBrokerClient to forward push/inbound frames to
the same handleBrokerPush the member-keyed broker already uses.
Pass the per-session secret key as sessionSecretKeyHex so
decryptOrFallback tries it first; member key remains the fallback
for legacy member-targeted traffic.

Verified end-to-end with two registered sessions sending in both
directions — inbox.db row count went 0 → 2.

Files: apps/cli/src/daemon/session-broker.ts,
apps/cli/src/daemon/run.ts. No broker change required.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Alejandro Gutiérrez
2026-05-04 17:33:18 +01:00
parent 7460d34335
commit a25102a79f
4 changed files with 71 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
apps/cli/CHANGELOG.md
View File

@@ -1,5 +1,39 @@
# Changelog
## 1.32.1 (2026-05-04) — DMs to session pubkeys actually deliver now
Critical fix. Sessions launched via `claudemesh launch` (1.30.0+) hold a
per-launch session WebSocket on the broker, separate from the daemon's
member-keyed WS. The broker correctly fans direct messages targeted at a
session pubkey out over THAT session WS — but the daemon's
`SessionBrokerClient` was constructed without a push handler and silently
dropped every inbound `push` / `inbound` frame. The header docstring
even claimed it handled "inbound DM delivery for messages targeted at
the session pubkey"; the code never wired the callback.
Net effect since 1.30.0: any DM sent to a peer's session pubkey
(everything `peer list` returns these days, since session pubkey is the
canonical routing key) was queued, broker-acked, marked `delivered_at`
on the broker side, and then thrown away by the recipient daemon. The
local `inbox.db` stayed at zero rows forever and `claudemesh inbox`
reported "no messages" no matter what arrived.
Two-session smoke test that surfaced this: peer A sent "hola" to peer
B's session pubkey — sender outbox showed `status=done` with a
`broker_message_id`, recipient inbox stayed empty, both sides confused.
The fix wires `SessionBrokerClient` to forward `push` / `inbound` frames
to the same `handleBrokerPush` the member-keyed broker already uses. The
session's secret key (registered via `/v1/sessions/register`) is passed
as `sessionSecretKeyHex` so `decryptOrFallback` tries it first; the
parent member key remains the fallback for legacy member-targeted
traffic that happens to fan out here.
Files: `apps/cli/src/daemon/session-broker.ts`,
`apps/cli/src/daemon/run.ts`. No broker change required — the broker
half (queue + fan-out + sendToPeer on the session WS) was already
correct; only the daemon-side intake was missing.
## 1.32.0 (2026-05-04) — multi-session UX bundle
Nine UX bugs surfaced from a real two-session interconnect smoke test