fix: iOS reconnects stop requesting approval after capability loss#102661
Conversation
openclaw-barnacle
Bot
added
gateway
|
Land-ready review complete at Proof:
Proof gap: no physical iPhone run. The focused suite includes the production Gateway WebSocket pair/reconnect path and reproduces the transient |
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: fix: iOS reconnects stop requesting approval after capability loss This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
|
Merged via squash.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0fc3a8bdf1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| caps: declaredCaps, | ||
| commands: declared, | ||
| permissions: declaredPermissions ?? (hasPermissionChange ? {} : undefined), | ||
| permissions: declaredPermissions ?? (permissionUpgrade ? {} : undefined), |
There was a problem hiding this comment.
When a paired node already has a pending permission reapproval and then reconnects with a command/capability upgrade but omits the permissions map, this now sends permissions: undefined; requestNodePairing treats undefined as “reuse the latest pending permissions” (src/infra/node-pairing.ts:215), so the replacement request can carry forward and later approve a stale permission that the current reconnect did not request. This only arises with an existing pending permission request plus a simultaneous non-permission upgrade, but it can broaden the durable approval beyond the live declaration; pass an explicit empty permission surface for omitted permissions in this reapproval path instead of letting pairing-state merge fill it from old pending state.
Useful? React with 👍 / 👎.
(cherry picked from commit 5b0e970)
1 participant
Closes #98038
What Problem This Solves
Fixes an issue where approved iOS devices could be sent back to the approval flow after reconnecting when transient device capabilities or permissions became unavailable, including Apple Watch reachability changes.
Why This Change Was Made
Treats an existing pairing approval as the maximum authority granted to the device. Reconnection now requires approval only when the device requests a new command, capability, or enabled permission; losing a previously declared capability or permission only narrows the live session and does not mutate the durable approval.
User Impact
Previously approved iPhones can reconnect after ordinary availability changes without repeated approval prompts. New authority still requires explicit approval.
Evidence
tbx_01kx35rs5ramy75wvs0jn0v4kt: focused Gateway pairing/reconnect tests, 6 files and 66 tests passed.tbx_01kx35rs5ramy75wvs0jn0v4kt:check:changedpassed, including typechecks, lint, import-cycle checks, and policy guards.The proof exercises the same Gateway WebSocket connect and pairing path used by iOS; no physical-device run was performed.