OpenClaw merged a P1 node-pairing authorization fix Monday night that tightens approval requirements for nodes declaring fs.listDir. The fix makes approval-time authorization match invoke-time authorization: operators now need operator.admin before approving a node surface that declares the file-listing command.
The bug was a scope mismatch. Invoking fs.listDir through node.invoke already required operator.admin, but approving a pending node that advertised fs.listDir could be done by an operator with only operator.pairing and operator.write.
Source: OpenClaw PR #106004
What Was Fixed
OpenClaw uses resolveNodePairApprovalScopes to decide which operator scopes are required when approving a pending node pairing. The approval resolver keeps an admin-level command list for commands that demand operator.admin at approval time.
fs.listDir was added to the invoke-time admin gate in earlier work, but it was not included in the approval-time admin list. That left an asymmetry:
- Execution required
operator.admin. - Approval could happen without
operator.admin.
PR #106004 adds NODE_FS_LIST_DIR_COMMAND to the approval-time admin command list, closing the gap.
Why It Matters
Node pairing is a trust boundary. Approval is where an operator decides whether a device or surface should be allowed into the OpenClaw environment with the commands it advertises.
File listing is not as visibly destructive as shell execution, but it is still an admin-sensitive capability. Directory structure can reveal project names, customer files, local system layout, mounted volumes, backup paths, and other sensitive operational context.
The important point is not that fs.listDir suddenly became dangerous. OpenClaw already treated invocation as admin-only. The fix makes the earlier approval step honor the same classification, so a lower-scope operator cannot bless a capability they would not be allowed to run.
Evidence
The PR includes both unit and integration proof. A focused unit test now confirms that resolveNodePairApprovalScopes(["fs.listDir"]) returns operator.pairing plus operator.admin.
The gateway integration path also continued passing across the node.pair.approve RPC flow, with coverage confirming no regression for system.run, browser.proxy, or non-admin command approval paths.
The real-behavior proof is the strongest part: with caller scopes operator.pairing and operator.write, a node surface declaring fs.listDir now returns a forbidden outcome with missing scope operator.admin. With operator.pairing and operator.admin, the same surface can be approved and persisted.
Watch The Pattern
The PR notes that this is the same class of approval-versus-invoke mismatch previously fixed for browser.proxy. It also explains why the approval and invoke admin-command lists are not simply identical: some commands have different approval-time and invoke-time semantics.
That makes the minimal P1 fix reasonable, but it also marks a policy area worth watching. Admin-sensitive node capabilities need consistent review paths, clear tests, and careful classification as OpenClaw continues expanding node surfaces.