* chore(release): close out 2026.6.10 on main
* chore(release): align native app metadata for 2026.6.10
* chore(release): sync Android 2026.6.10 notes
* docs(changelog): preserve 2026.6.9 history
* docs(changelog): preserve 2026.6.9 history
Bumps OpenClaw release metadata to 2026.5.31 across package manifests, app version files, plugin metadata, changelog headings, and generated shrinkwraps.
Verification:
- pnpm plugins:sync:check
- pnpm ios:version:check
- pnpm deps:shrinkwrap:check
- git diff --check
- stale 2026.5.30/build-code scan across changed files
- autoreview clean: no accepted/actionable findings
- PR CI green for real gates: Checks, security scans, dependency guard, app lanes, real behavior proof
Known non-code workflow issue:
- label workflow failed because this PR hits GitHub's 100-label issue cap before the size-label step.
* fix(matrix): close owner-side device verification loop on SAS confirm
After SAS confirm via the `openclaw matrix verify confirm-sas` CLI, the
operator's Element X stayed in "Verifying…" because three things on the
bot side did not happen before the verb returned:
1. confirmVerificationSas didn't await the rust-crypto verifier promise.
`Verifier.verify()` resolves only after both sides exchange MACs and
the protocol fully settles, including cross-signing-key uploads
triggered by `crossSignDevice`. Returning early meant Element X's
next /keys/query saw an inconsistent state and the prompt persisted.
2. The 30s auto-confirm path (used when the operator initiates from
their phone) explicitly passed `{ trustOwnDevice: false }`, so the
bot never cross-signed its own device on this path. The check inside
trustOwnDeviceAfterConfirmedSas already gates on isSelfVerification,
so flipping the flag is safe — non-self requests remain a no-op.
3. The standalone `confirmMatrixVerificationSas` action did not call
`trustOwnIdentityAfterSelfVerification` (only the higher-level
`runMatrixSelfVerification` path did). Without that call, the bot
had not signed the operator's master key, so Element X had no path
to clear the prompt without a passive sync tick.
Three additive edits:
- verification-manager.ts (confirmVerificationSas): await
session.verifyPromise after confirmSasForSession returns.
verifyPromise is the .then().catch() chain set by
ensureVerificationStarted, which already routes rejections into
session.error, so awaiting it cannot double-throw.
- verification-manager.ts (maybeAutoConfirmSas): pass
{ trustOwnDevice: true } so the auto-confirm path also cross-signs
the bot device for self-verifications.
- actions/verification.ts (confirmMatrixVerificationSas): mirror the
trustOwnIdentityAfterSelfVerification call from
completeMatrixSelfVerification when the returned summary indicates
isSelfVerification.
Tests:
- verification-manager.test.ts: flipped the existing "auto-confirmed
self-verification" assertion (now expects trustOwnDeviceAfterSas to
be called); added two new tests for verifyPromise await and
rejection-on-summary.error.
- actions/verification.test.ts: two new tests asserting
confirmMatrixVerificationSas calls trustOwnIdentityAfterSelfVerification
on self-verifications and not on remote verifications.
Verified end-to-end against matrix.thepolycule.ca (Synapse 1.145.0+ess.1,
MAS-fronted): after `verify confirm-sas`, Element X's device-list view
shows the bot device with a green shield and no pending Verify prompt.
* fix(matrix): guard owner trust after failed SAS verification
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
