Repository navigation
Read no pairing frame while a confirmed pairing's write is in flight - #1237
Merged
Merged
Conversation
Once the person at the Burrow confirms the digits and the ACL write starts, local consent is final. A pairing transport frame that failed to decrypt still disposed the ceremony as `burrow-error`, skipping the committing guard: the laptop reported a failure while the write landed, and the phone never heard the outcome. Pairing frames are now ignored while committing, so the write's own result is what both ends hear. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deploying mouseterm with
|
| Latest commit: |
1eff055
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://3c3822ca.mouseterm.pages.dev |
| Branch Preview URL: | https://pairing-commit-transport.mouseterm.pages.dev |
nedtwigg
requested a deployment
to
hosted-preview
October 20, 2026 15:19 — with 
GitHub Actions
Waiting
GitHub Actions
Waiting
dormouse-bot
left a comment
dormouse-bot
left a comment
Collaborator
There was a problem hiding this comment.
The fix looks correct and I have no findings. The committing guard closes the one ending that skipped #finishPairing. Withholding approval only because the Workflow Lint check is red: zizmor flags a hash pin in ci.yml (line 403) whose version comment doesn't match the tag. This PR doesn't touch .github/, and main's latest Workflow Lint run (at ed40d010) fails the same way, so the fix belongs on main.
…ring test Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dormouse-bot
approved these changes
Oct 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hardening for the end of a pairing ceremony.
Once the person at the Burrow types the matching digits and the ACL write starts, local consent is final: teardown may drop the pipe, but nothing may cancel the write or announce a denial. One path did not honor that. In
#onPairingTransport(lib/src/remote/burrow/burrow-runtime.ts), a transport frame that failed to decrypt disposed the ceremony asburrow-errordirectly, skipping thecommittingguard every other ending goes through. The write still landed, so the laptop said the pairing failed while the record was saved, and the retired ceremony meant the phone never received its outcome.Tests
lib/src/remote/burrow/burrow-runtime.test.ts→ "lets no pairing frame end a ceremony whose write has started": an undecryptable frame arriving mid-write leaves the invitation reserved; when the write completes the record is live, the phone decryptsok: true, and the invitation retires aspaired. It goes red with the fix reverted.Specs
docs/specs/remote-security-model.md→ "Pairing": the consent-is-final rule now says pairing frames arriving during the write are not read.🤖 Generated with Claude Code