OpenClaw Retires Phone Control Arming Leases: Node Consent Is Now Durable on Main

OpenClaw has merged a breaking authorization-model change into main: temporary Phone Control arming leases and the /phone arm/disarm commands are retired. For interactive computer and mobile UI control, node-local enablement plus pairing approval now represents durable consent.

This is not in 2026.7.2-beta.5: the beta was published at 03:23 UTC on 28 July, while the merge landed at 03:51 UTC. Source-build operators and anyone evaluating the next containing release need to treat it as a security-boundary migration, not plugin cleanup.

The operator decision

The crucial point is persistence. Before this merge, an operator could view pairing and node-local enablement as necessary but still expect an expiring Gateway lease before interactive control. Upstream has explicitly decided that the lease was an implementation layer, not an additional consent promise.

What was removed

The merge deletes the bundled phone-control extension and its lease machinery, including:

• /phone arm and /phone disarm;
• lease journals and expiry services;
• the fresh-setup 12-command deny seed associated with that model; and
• the requirement for a persistent command allow entry for computer.act, mobile.ui.observe and mobile.ui.act when their node-local capability is enabled and pairing is approved.

It adds no replacement lease switch or new configuration key. That is why existing operational procedures based on periodic re-arming will stop working rather than map to a renamed command.

The new ownership boundary

The merged design separates authority by command class:

1. Interactive computer and mobile UI control — default-off enablement on the node plus pairing approval is the complete durable gate.
2. Capture and personal-data commands — continue to require persistent Gateway command policy where documented.
3. Explicit deny policy — still wins over allow policy.
4. Legacy-state retirement — belongs exclusively to openclaw doctor --fix, not an implicit compatibility reader at Gateway startup.

Interpretation: physical or local enablement now carries more lasting weight. An operator who enables control once and pairs the node should expect that decision to survive restarts and upgrades until they disable the capability, revoke pairing or impose policy that denies it.

Why Doctor matters on upgrade

The difficult case is an existing installation carrying the old setup seed, lease-owned grants, customized policy or ambiguous legacy state. The final merged migration is designed to distinguish them.

According to the pull request, Doctor:

• removes temporary allow entries and restored deny entries owned by the lease journal;
• retires unshadowed entries from the exact historical setup seed;
• preserves exact-seed denies that still shadow explicit allows;
• leaves customized or operator-authored policy untouched;
• treats SQLite as authoritative over a stale legacy file;
• fails closed on malformed, inaccessible or ambiguous state; and
• retains the canonical journal until legacy state is archived after persistence.

Supported update flows run the target version’s Doctor repair before restart. Direct package replacement must reproduce that order. Starting the new runtime first and hoping it interprets old lease state is explicitly outside the design.

Safe migration sequence

1. Identify a containing build. Do not apply this procedure to beta.5 merely because the merge exists on main.

2. Inventory node authority. Record paired nodes, local control toggles and relevant allow/deny entries without exposing device identifiers or private data.

3. Decide the policy before upgrade. If durable interactive control is unacceptable, disable it locally or add an explicit deny through supported configuration before adopting the change.

4. Back up complete state and configuration. Preserve the SQLite family, configuration and legacy Phone Control evidence.

5. Stop the old Gateway and run the target Doctor:

   openclaw doctor --fix

6. Review every reported removal. A customized policy entry should not disappear merely because it resembles the historical seed.

7. Restart and test both outcomes. Prove an intended interactive action can run and an explicitly denied action remains denied.

8. Revoke stale pairings. Durable consent makes forgotten paired devices more important; remove any node that should no longer participate.

9. Retain the backup and migration evidence until control, capture and personal-data policy has survived another restart.

If Doctor reports ambiguous or unreadable legacy state, stop. Do not delete the journal, plugin reference or deny list by hand just to make startup quiet.

Security interpretation

Upstream’s initial automated review correctly identified the migration as capable of broadening durable authorization: removing the historical deny seed could make an already enabled and paired node invocable without the former expiring lease.

The maintainer then made the product decision explicit: for existing installations as well as fresh setups, node-local enablement plus pairing counts as durable consent. The final pull-request record also adds a sanitized seeded-upgrade run and focused migration evidence before merge.

That resolves ambiguity about intended behaviour. It does not mean every operator shares that threat model. If pairing approval is delegated, nodes are shared, or temporary time windows are a compliance requirement, replace the retired lease process with explicit local disablement, pairing revocation or deny policy. Do not assume another hidden time gate remains.

Evidence and limits

The merged pull request reports a real sanitized Doctor run, 644 assertions across the surviving focused files after rebase, a 12-test final migration suite and passing exact-head CI. OpenClaw Academy reviewed the official pull-request record, final owner decision and landed commit chronology. We did not pair a real phone, migrate a production lease journal or execute node control. Test and runtime proof is attributed to upstream.

Bottom line

OpenClaw has chosen one durable consent model over two stacked ones. That removes operational friction and a substantial lease subsystem, but it also removes the temporary gate some operators may have relied on.

Before adopting a containing build, decide whether an enabled and paired node should stay authorized indefinitely. Run Doctor in the supported order, verify what it retires, and encode any stricter boundary explicitly rather than waiting for /phone arm to expire—it no longer exists.