active, give the agent a stable
active-node hint, and route node connection alerts to the computer where you
are most likely present.
This is a recent-activity hint, not proof of which computer sent a particular
chat message. The active Mac can differ from the computer running the Gateway
or agent, and another person’s input can change the selection.
This is separate from system presence, which is the live
roster of Gateway clients, and from durable node.presence.alive beacons, which
record when a mobile node last woke without treating it as connected.
Requirements
- The OpenClaw macOS app is paired and connected in node mode.
- Interact with the OpenClaw app to provide basic presence. Merely running or foregrounding the app does not count as activity.
- To include activity in other apps, enable Settings -> Permissions -> System-wide presence detection and grant Accessibility to the signed OpenClaw app. System-wide detection is off by default.
- For connection alerts, Notifications permission is also granted and the
Mac node exposes
system.notify.
Check the active computer
- Interact with the OpenClaw macOS app. No Accessibility permission is needed for this basic presence signal. To detect activity in other apps too, enable Settings -> Permissions -> System-wide presence detection and grant Accessibility in macOS System Settings.
-
Confirm the Mac node is connected:
-
Click or type in OpenClaw on that Mac, then run:
active. Status output shows its last-input
age; describe exposes active, lastActiveAtMs, and presenceUpdatedAtMs.
Activity is intentionally coalesced, so the display may take up to about 15
seconds to reflect another input after a recent report.
How activity becomes presence
The macOS app records local input events received by OpenClaw. When system-wide detection is enabled and Accessibility is granted, it also samples the HID system idle clock every two seconds. Reports are coalesced: newer activity is sent no more than once every 15 seconds, with a keepalive every three minutes while idle. Idle duration is capped at 30 days so a very old sample cannot drift forward and incorrectly become the newest computer. Disabling System-wide presence detection, or losing Accessibility, clears the previous system-wide sample and falls back to app-local activity if any has been observed. It does not turn off basic presence or disconnect other node capabilities. Without an app-local sample, that Mac remains unselected until you interact with OpenClaw. The Gateway accepts activity only when all of these are true:- the event belongs to the current authenticated connection for that node id;
- the payload contains a bounded integer
idleSecondsvalue; - the source is app-local, or system-wide with effective
accessibility: truepermission. Legacy reports without a source are treated as system-wide.
idleSeconds from its own observation time to derive
lastActiveAtMs. It never trusts a node-supplied wall-clock timestamp. Among
connected eligible Macs, the newest lastActiveAtMs wins; a tie uses the most
recent presence update.
Presence is process-local and connection-bound. Disconnecting the current
session or replacing it with another session using the same node id clears that
node’s activity state and recomputes the active Mac. Revoking Accessibility
invalidates system-wide activity, but app-local activity remains eligible.
Privacy and model context
Basic app-local presence is available without an Accessibility grant. Only system-wide detection is opt-in, separately from the Accessibility grant used for UI automation. OpenClaw sends idle duration and the activity source, not input content. It does not send key values, mouse coordinates, application names, window titles, or raw input events. System-wide detection reads the hardware HID state, so synthetic computer-control events do not count as physical system-wide activity. App-local detection records input delivered to OpenClaw and is not proof that an event came from a physical device. Continuous activity does not create model-facing system events. At turn preparation, the dynamic context contains a compact hint with only the authenticated node id:active_node=unknown. This clears a previous selection rather than leaving the
agent to reuse a disconnected Mac. It does not identify the message’s source
device or imply that no one is using a computer.
Exact timestamps and node-controlled display names stay out of the prompt to
avoid prompt injection and cache churn. The hint stays byte-for-byte identical
while the selected node id is unchanged. When the agent needs current details,
the nodes tool can read node.list or node.describe instead.
How connection alerts are routed
After a node finishes its first successful Gateway handshake after approval, OpenClaw waits 750 milliseconds so the connecting Mac can submit its first activity sample. It then tries the connected notification-capable Mac with the freshest activity.- If primary delivery succeeds, no other Mac receives the alert.
- If no active Mac is available or primary delivery fails, OpenClaw waits five
seconds and tries every remaining connected Mac that exposes
system.notify. - Later reconnects are silent. The Gateway records the successful connection in pairing metadata, so a Gateway restart does not replay alerts for every previously connected node.
Troubleshooting
For TCC recovery, see macOS permissions. For node
connection and command failures, see Node troubleshooting.