fix(mesh): attribute command results, stop broadcasting device commands, bind transfer tokens, bound the registry

[claudiusthebot]

Follow-up to #648, which covered the remotely-reachable bridge issue. These four are the mesh-side findings from the same audit — reachable by a connected/compromised companion device rather than by an arbitrary website.

1. completeCommand device-spoofing bypass

service.ts: if (from && from !== pending.deviceId) return false; — the empty-string fallback (kept "for older app builds") meant a reply that omitted deviceId skipped the ownership check entirely. Combined with #2, any connected device could race and feed the model fabricated exec stdout or a fake install success.

result with NO deviceId    -> accepted (resolved with spoofed stdout)
result with WRONG deviceId -> rejected   <- the check only worked when the field was present

Now rejected outright rather than "accept when exactly one command is pending" — the one-pending variant still can't attribute the reply, it only narrows the window to whenever the mesh is idle, while looking like a check. Back-compat cost is nil: deviceId has always been in the command-result wire contract (protocol/fixtures/mesh_v1.json, asserted by daemon/node/companion conformance tests) and both shipped clients already send it.

2. Device commands were broadcast to every SSE client

Comments claimed "each client filters by its own device id" — client-side courtesy, not enforcement. Every connected client received one-time transfer tokens, exec command lines, remote paths, and on the chunked fallback the entire base64 file body. A device_push_file to phone A handed the file to phone B.

Clients now name themselves with GET /events?deviceId=…; sendToDevice() delivers device_command to the claiming client(s) only. locate still fans out (no secret in the frame, and pre-command builds depend on it). A client that claims nothing receives a command only when nobody claimed its target, so updated devices' traffic is never visible to legacy clients and the fallback shrinks as the fleet updates.

3. Transfer tokens weren't bound to their device

transfers.ts take() validated token/direction/expiry but never that the peer was the device the token was minted for — so a second device could consume another's push token (→ arbitrary daemon-host file) or satisfy a pull token (→ attacker bytes written to the daemon's destination). Now checked, and checked before the single-use latch so a wrong claim can't burn the real device's token.

Deliberate concession: an absent claim is still served. Making it mandatory would break the transfer that ships the client build able to make it — update_device/update_node push the new binary over download_file, so a daemon upgraded ahead of its fleet would refuse the very transfer that updates the fleet. Dropping the fromDeviceId && guard later makes it mandatory in one line.

4. Unbounded registry growth

sanitizeDevice bounded only arch and capabilities; id/name/appVersion were unbounded to the 256 KB body cap, and storeLocation accepted any deviceId — registered or not — rewriting all three sidecar files in full each time.

one registration with 100000-char fields -> mesh-devices.json = 300141 bytes
50 locations for never-registered ids    -> all 50 persisted

Caps: id 128 (refused if longer — truncating an identity key would merge devices), name 128 / appVersion 64 (clamped, display-only), device map capped at 128 with least-recently-seen eviction, orphan locations capped at 16.

Verification

tsc --noEmit, oxlint, prettier --check clean. Full non-integration suite passes (4067). New tests cover each fix through real code paths, including two live SSE connections proving a command reaches only the claiming client while broadcast still reaches everyone, and an over-HTTP check that a rejected transfer claim doesn't burn the token.

Please double-check

• The Go and Dart client changes are unbuilt. Neither toolchain is installed in my environment. The edits are small and inspect clean (n.DeviceID exists, net/url already imported; eventsUrl() output is unchanged when no id is passed, so bridge_models_test.dart should still pass) — but they want a real build.
• Claim spoofing remains possible: any client holding the bridge bearer token can claim another device's id. There's no per-device credential in this protocol, so that's the same trust boundary as before — this removes passive leakage, not a privileged attacker. The single shared bridge token across all mesh devices is the underlying design issue and is not addressed here.
• On a brand-new companion install the very first stream may connect unclaimed, with the claim landing on the next reconnect. Falls back safely rather than dropping commands.

Most of this work was done by a parallel agent in an isolated worktree; I rebased it, re-verified it in a working environment (its own run had 17 environmental failures from an empty node_modules), and reviewed the diff.

🤖 Generated with Claude Code