openclaw - 💡(How to fix) Fix Already-paired macOS node still requests approval on every app relaunch (2026.5.28-beta.4)

Summary

Already-paired local macOS nodes can still trigger a fresh Allow node to connect? approval prompt on every OpenClaw.app relaunch. Re-pairing from scratch does not resolve it.

This is related to #87382, but I am filing this separately because the repro below is on 2026.5.28-beta.4 and points to a gateway-side node.pair.request handling issue rather than only a stale/corrupt pairing record.

Environment

• CLI/Gateway: OpenClaw 2026.5.28-beta.4 (b717704)
• macOS app bundle: 2026.5.27 (CFBundleVersion=2026052790)
• macOS: 26.5 (25F71)
• Install kind: npm package under /opt/homebrew/lib/node_modules/openclaw

Reproduction

1. Start with a paired local macOS node.

2. Confirm no pending node approval:

   openclaw nodes pending --json
   # []

3. Confirm the same node is already paired and connected:

   openclaw nodes status --json
   # paired: true, connected: true

4. Quit and reopen /Applications/OpenClaw.app.

5. Observe a new Allow node to connect? prompt for the same node id/display name.

6. Gateway logs show another node pairing approval path after relaunch, even though the node was already paired.

I also tested deleting the node entry from ~/.openclaw/nodes/paired.json, reopening the app, and manually approving the new prompt. The node paired successfully, but the prompt returned again on the next app relaunch. That rules out a simply corrupt old node pairing record.

Expected Behavior

If state.pairedByNodeId[nodeId] already exists and the incoming request has the same approval surface, relaunching the macOS app should not create a new pending approval request.

The gateway should only require a new approval when the node requests a meaningfully expanded approval surface, such as new caps or commands.

Suspected Cause

requestNodePairing() in dist/node-pairing-*.js appears to reconcile only existing pending requests for a node. It does not short-circuit when state.pairedByNodeId[nodeId] already exists.

That means a relaunch-time node.pair.request from an already-paired macOS app node can still create another pending approval request.

Local Mitigation Tested

I tested a local gateway-side mitigation:

• If state.pairedByNodeId[nodeId] exists and the incoming request has the same caps and commands, refresh paired node metadata and remove pending requests for that node instead of creating a new pending approval.
• Keep the normal approval flow when the node declares new caps/commands.

After applying that local mitigation and restarting the gateway, I relaunched the macOS app twice:

• openclaw nodes pending --json stayed []
• no new node.pair.approve appeared in the gateway log
• node status returned to paired: true, connected: true

This suggests the issue can be fixed safely on the gateway side without auto-approving expanded node capabilities.