-
-
Notifications
You must be signed in to change notification settings - Fork 80.7k
[Bug]: Mac app floods unbounded stacked device pairing approval alerts for one retrying device; approving stale alerts is a no-op #100974
Copy link
Copy link
Closed
Labels
P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.Emergency: data loss, security bypass, crash loop, or unusable core runtime.bugSomething isn't workingSomething isn't workingclawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.ClawSweeper found an open linked pull request for this issue.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.Auth, provider routing, model choice, or SecretRef resolution may break.impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.A non-technical user is blocked without terminal, logs, config, or support.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.maintainerMaintainer-authored PRMaintainer-authored PRmaturity:stableIssue affects a taxonomy feature currently scored M4/M5.Issue affects a taxonomy feature currently scored M4/M5.
Description
Metadata
Metadata
Assignees
Labels
P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.Emergency: data loss, security bypass, crash loop, or unusable core runtime.bugSomething isn't workingSomething isn't workingclawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.ClawSweeper found an open linked pull request for this issue.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.Auth, provider routing, model choice, or SecretRef resolution may break.impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.A non-technical user is blocked without terminal, logs, config, or support.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.maintainerMaintainer-authored PRMaintainer-authored PRmaturity:stableIssue affects a taxonomy feature currently scored M4/M5.Issue affects a taxonomy feature currently scored M4/M5.
Type
Fields
Priority
None yet
Summary
The Mac app stacks an unbounded pile of "New Mac wants to connect" device-pairing approval alerts (~100 overnight) for a single retrying device, and clicking Approve on them does nothing except reveal the next stale alert.
Steps to reproduce
Expected behavior
One approval alert for the device. Approving it pairs the device; no further alerts for the same device unless it asks for more access.
Actual behavior
Dozens of stacked alerts for the same device (screenshot showed
ID d34f4111...80b45ad · repair requestrepeated ~100 times). Each Approve on a stale alert is a silent no-op (unknown requestIdon the gateway) and the next stale alert pops, one per click.Root cause (from source)
src/infra/device-pairing.ts: a pending request expires 5 minutes after creation even while the device is actively retrying — refresh preservests(anti queue-jumping) and the TTL prune also keys onts. Every 5 minutes the pending request is silently pruned and the next reconnect mints a newrequestId+device.pair.requestedbroadcast (~12 fresh alerts/hour).device.pair.resolvedbroadcast (the node-pairing path insrc/infra/node-pairing.tsalready emits these), so clients never learn the old requestIds are dead.apps/macos/Sources/OpenClaw/DevicePairingApprovalPrompter.swift: the alert queue never expires entries, dedupes by full struct equality instead of requestId, and never coalesces per device, so stale alerts accumulate unboundedly.OpenClaw version
2026.6.11 (repo main, 5733fb0)
Operating system
macOS 26.5
Install method
mac app + pnpm dev gateway
Model
n/a (device pairing; no model involved)
Provider / routing chain
n/a — Mac app -> gateway WS
connectdevice pairing