maybeMigrateAuthProfileJsonStoresToSqlite discarded the error from
resumePendingAuthProfileMigrationArchives entirely, so the warning was always
the same generic string regardless of which of 5 distinct causes fired
(invalid receipt, target verification failure, lock failure, SQLite failure,
corrupt JSON). PR #123164 fixed the identical defect class in the sibling
shared-OAuth catch block 20 lines below in this same function, explicitly
modeling the fix on the third, already-correct sibling. This was the
unaddressed third catch block in that same family.
* fix(gateway): stop fabricating scope-upgrade requests on trusted-proxy reconnects
Same-key trusted-proxy reconnects whose auto-approvable scopes are already
covered by the paired grant now narrow the session in place instead of
running the pairing request/approve machinery: no pending-store writes and
no false 'device access upgrade requested' / 'auto-approved' security-audit
warns on every Control UI page load. The upgrade audit warn moved into
requirePairing so it fires only when a pairing request is materialized.
Durable widening (broadened deviceAutoApprove.scopes) and key-mismatch
repairs keep the existing lanes.
* fix(gateway): revalidate the live paired grant in the reconnect fast path
Address ClawSweeper P1: the narrowing decision now rereads the
authoritative paired row as the last await before returning, so a
concurrent revoke, key replacement, or grant reduction fails closed into
the pairing lane instead of riding the pre-plan snapshot. Extract the
pairing approval-plan resolver into connect-pairing-approval-plan.ts to
keep the authorization owner under the 700-line lint boundary.
* fix(buzz): messages sent during Gateway downtime are dropped after restart
Every new Gateway process subscribed to Buzz rooms starting at its own
start time, because the lookback flag that enables backlog paging is
process-local. That cutoff is applied as the NIP-01 since filter, so any
room message a human sent while the process was down was never returned
by the relay and never reached the agent or the transcript.
The account gateway now persists a per-account recovery watermark in the
plugin state store. First-ever setup still starts from the current time;
later process starts resume from the saved watermark, clamped to the
existing 24 hour retention floor. The watermark advances only after
inbound handling completes and is stored at the admitted message
created_at, so the inclusive since boundary re-offers the last admitted
message to the existing persistent event-id dedupe guard.
* fix(buzz): keep the cold-start recovery cursor behind unfinished work
Codex review found two ways the recovery watermark could still drop room
messages. Backlog replay dispatches up to eight handlers concurrently, so
a newer message finishing before an older one committed the newer
timestamp; a crash then left the older message with no dedupe record and
a cursor already past it. The stored timestamp was also the sender
controlled created_at, so a future dated room event pushed the cursor
past locally observed time and excluded real downtime messages on the
next start.
The account gateway now tracks a recovery frontier per session. A
checkpoint is the highest completed message time bounded by the oldest
still running message, the oldest failed message, and the receipt time
observed when the message was admitted. Checkpointing stays closed until
the bus reports the room backlog fully drained, so a session that is
still paging history cannot commit past events it has not seen yet.
catchUpHistory now reports drained or incomplete for that signal.
* fix(buzz): scope cold-start recovery per room and fence it at enqueue
Admit replay work into the recovery frontier when it enters the dispatch queue instead of when a worker starts it, so a crash cannot persist a cutoff past an event that is still queued.
Key recovery cursors by room instead of by account, so a room configured after the first start resolves to the current time and gets no backfill, while existing rooms resume from their own cursor.
Record an account-level start marker so the first start under a watermark-aware build recovers the existing retention window instead of repeating the reported loss on the first restart after an upgrade.
* fix(buzz): keep cold-start recovery to accounts that already ran
An account with no persisted cursor is a fresh install as often as it is a
pre-watermark upgrade, and stored state cannot tell them apart, so the first
start no longer replays the retention window. It records the current time as
each room cursor and recovers only from the second start onward.
Dropping the account start marker also removes the interrupted-bootstrap
window where a marker written before the room cursors made the next start
treat cursor-less rooms as initialized.
Recovery state capacity is now derived from the supported room limit instead
of a smaller fixed number, and any non-complete history paging outcome, not
just timestamp-over-limit, holds the recovery frontier undrained.
* fix(buzz): bound the recovery cursor store to each account
ClawSweeper found that the recovery watermark opened one fixed plugin-state
namespace for every account while sizing it at the per-account supported room
count. Plugin-state capacity is enforced per plugin and namespace, so once one
account registered its full room allowance, a second account's register call
threw and its rooms stayed at the current-time cutoff, which is the same
dropped-message outcome this PR set out to fix.
The store is now opened against a namespace derived from the account identity,
so each account carries its own supported room capacity. The account moves out
of the entry key into the namespace, which leaves one account-scoped store path
rather than a fallback, and makes cross-account cursor mixing unrepresentable.
* fix(buzz): simplify durable restart recovery
Co-authored-by: yetval <yetvald@gmail.com>
* test(buzz): use real relay response in recovery fixture
Co-authored-by: yetval <yetvald@gmail.com>
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* refactor(state): retire six dead shared-state tables at schema v10
agent_model_catalogs, android_notification_recent_packages,
command_log_entries, diagnostic_stability_bundles, media_blobs, and
model_capability_cache landed with the database-first squash but their
runtime writers never reached main; every stable since v2026.6.10 created
them empty (agent_model_catalogs held only rebuildable catalog cache rows
until #111173 removed its writer). State schema 10 drops all six tables
and seven indexes through both the runtime-open and doctor migration
paths, records the retirements, bumps the native reader ceiling, and
corrects stale database-first doc claims that still named these tables
as canonical stores.
* test: move cross-lane schema-version pins to v10
The v10 retirement missed current-version pins outside src/state: the
native guard vitest wrapper, placement-move and node-worker-launch
same-version assertions, and the audit outbound-progress tripwire. The
pinned pre-C04 audit reader is a v9-era build that now refuses v10
databases by the version contract, so the test projects the file back to
the exact v9 shape with the documented 10-to-9 downgrade fixture before
the reader proof; the shared fixture also seeds the v10 retirement
regression.
* test: keep only the used downgrade fixture export
The startup SECURITY WARNING and the critical security-audit remediation for
gateway.auth.trustedProxy.deviceAutoApprove.scopes containing operator.admin
still told operators to wait "until per-identity roles are available".
Per-identity admin grants shipped as gateway.auth.identityScopes and the
trusted-proxy docs already recommend them; the runtime guidance now names
that shipped fix instead of a nonexistent future feature.
Dallin Romney