Skip to content

fix: consistent device ID derivation in invite/listen - #16

Merged
YairEtzion merged 1 commit into
mainfrom
fix/device-id-derivation
Apr 4, 2026
Merged

fix: consistent device ID derivation in invite/listen#16
YairEtzion merged 1 commit into
mainfrom
fix/device-id-derivation

Conversation

@YairEtzion

Copy link
Copy Markdown
Contributor

Summary

  • Bug: invite and listen derived device IDs with raw base64url(pubkey) while init used SHA-256(pubkey) — the relay could never match controller's allow list entry to the agent's registration, silently breaking shell routing
  • Fix: All 4 invite/listen files now use generateDeviceId() from identity.ts (SHA-256 based)
  • Note: Existing pairings need re-pairing after this fix

Changes

  • packages/cli/src/commands/invite.ts — use generateDeviceId()
  • packages/cli/src/commands/listen.ts — use generateDeviceId()
  • packages/agent/src/commands/invite.ts — use generateDeviceId()
  • packages/agent/src/commands/listen.ts — use generateDeviceId()

Test plan

  • Manual: paired Mac → Pi, verified device IDs match on both sides
  • Manual: amesh shell testpi -c "whoami" succeeds end-to-end

🤖 Generated with Claude Code

invite and listen derived device IDs with raw base64url(pubkey) while
init used SHA-256(pubkey). The relay matches on device ID, so the
controller's allow list entry never matched the agent's registration,
breaking shell routing silently (relay sends fake peer_found per C3 fix).

All 4 files now use generateDeviceId() from identity.ts (SHA-256 based),
matching what init produces. Existing pairings need re-pairing.
@YairEtzion
YairEtzion merged commit 371944f into main Apr 4, 2026
1 check passed
@YairEtzion
YairEtzion deleted the fix/device-id-derivation branch April 4, 2026 11:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant