Secure Cross-Device AI Agent Handoff: State, Approval, and Recovery

Four Types of Agent Continuity

A secure cross-device AI agent handoff starts by naming the continuity pattern correctly. Remote steering means the task keeps running in its original environment while another device monitors and directs it. Task migration moves execution and enough state to a new environment. Notification continuation alerts another device and provides a route back to the task. Same-device continuity keeps one task accessible through different interfaces on the same phone.

These patterns can look similar to the user, but their operational requirements differ. If a development agent runs in a terminal and a phone queues another instruction, the terminal remains the execution owner. If a task genuinely migrates from a laptop to a phone, the phone must receive compatible inputs, credentials, tools, state, and permission context. A notification containing a deep link transfers even less: it identifies the waiting task but does not relocate its execution.

Movement between Android Home and a floating assistant is another useful pattern. The interface changes while the phone, task, tools, and permissions remain in the same runtime. FoneClaw's currently available capabilities use this form of one-phone continuity. It keeps supported execution, approvals, stopping, and permission recovery reachable as the user moves between Home and the floating assistant.

The first question for any handoff claim is therefore: where is the task actually running? The next questions are who can steer it, which device can approve a consequential step, and what happens if either interface disappears. Mobile Agent Control: Why the Phone Is Becoming the AI Agent Command Center explores why phones are particularly useful for monitoring and directing work that may execute elsewhere.

The Minimum Task-State Contract

A chat transcript is useful context, but a resumable agent task needs structured state. At minimum, the handoff must identify the user and session, preserve the bounded intent, reference the relevant inputs, name the current step, expose produced outputs, identify the execution owner, and state when the information was last verified. Without those fields, the receiving interface can display conversation history while remaining unable to determine what is safe to continue.

Freshness is essential because the world can change during handoff. A branch may receive another commit, an Android screen may move, a contact may change, or an approval token may expire. Before continuing, the execution owner should revalidate any state that affects the next action. Personal context also needs a bounded role; Personal Context AI Agent for Phone Actions: What Matters explains how useful context can remain connected to a specific phone task rather than becoming an unlimited pool of assumptions.

Bind Permissions and Approvals to Execution

Permissions belong to the environment that will perform the action. A phone may be authorized to steer a remote session, but the source computer still determines whether its CLI can access a repository, run a command, or use local credentials. Conversely, approval displayed on a laptop does not grant an Android app the microphone, contacts, notification, or accessibility access needed for a phone action.

Every approval should identify the task, proposed action, target, execution owner, and current consequence. Suppose a remote interface asks to approve a command. The user needs to know which running session requested it, which environment will execute it, what command or tool is involved, and whether the request remains current. If the task changed after the approval card was created, the old decision should expire rather than authorize the revised action.

The same rule applies to Android. A FoneClaw task may interpret a request through a configured model, but governed Android tools perform supported phone actions. The relevant Android permission and session-bound approval stay connected to that task on the phone. Moving between Home and the floating assistant preserves access to the decision; it does not change which runtime will act.

Approval design also needs a clear response path: approve once, deny, revise the proposal, or stop the task. A durable approval record should show who decided, from which trusted interface, for which action, and what happened afterward. For detailed mobile patterns, see AI Agent Approval UX on Phones: Confidence, Rationale, and Recovery.

Recover From Sleep, Disconnection, and Stale State

A handoff protocol should assume that connections will fail. The source device may sleep, the phone may lose its network, the app may be removed from memory, or the user may open a newer task from another interface. These events need explicit states such as disconnected, paused, waiting for source, stale, expired, or needs reauthorization. A frozen progress indicator leaves the user unable to tell whether work continues.

Remote steering is easiest to reason about when the source environment remains authoritative. If the remote phone disconnects, the source session can continue only within its existing instructions and approval state. New remote input waits until the connection is restored. If the source session ends, the remote interface should report that terminal state instead of pretending it can continue locally. Reconnection should compare session identity and the latest sequence number before accepting queued commands.

Task migration requires more work. The receiving environment needs a compatible task version, validated inputs, available tools, and a fresh permission check. Any in-flight external action needs an idempotency rule so reconnection does not send the same message, create the same event, or apply the same update twice. Expired transfer credentials should force a new authenticated handoff.

App-state changes require revalidation too. An Android approval prepared for one visible button cannot safely apply after the screen moves to another app or dialog. Recovery should return the user to the affected task, explain what changed, and offer retry, revise, stop, or touch takeover. A secure design treats interruption as an ordinary state transition, not an exceptional mystery.

GitHub Copilot CLI as a Remote-Steering Pattern

GitHub Copilot CLI remote control is a current example of remote steering rather than task migration. According to GitHub's general-availability announcement for Copilot CLI remote control, users can access a running CLI session from GitHub Mobile, github.com, and supported IDE interfaces. The original CLI environment continues running the session and remains the execution owner.

The remote interface can stream progress, steer the agent, queue input, answer questions, approve or deny permission requests, and stop the session. This design gives the user another control point without copying the active development environment onto the phone. Repository files, local processes, and CLI credentials remain associated with the source environment; the remote device exchanges authenticated session commands and status.

GitHub's Copilot CLI remote-control documentation also describes access from mobile, web, VS Code, and JetBrains environments. The useful architectural lesson is that the control interface and execution owner can be different while sharing one session identity, ordered events, permission requests, and stop controls.

In July 2026, GitHub Mobile added live Copilot CLI session notifications on iOS and Android. Notifications extend awareness when the user leaves the active remote view, but the running session remains in its source environment. This pattern works because the product makes execution location, session identity, remote commands, approvals, and termination behavior explicit.

FoneClaw Continuity on One Android Phone

The current released FoneClaw baseline addresses continuity within one Android phone. Its movable floating assistant and compact panel let the user move between the Home screen, another visible Android context, and FoneClaw controls while staying connected to the same task. The phone remains the execution environment throughout.

One-tap current-screen attachment gives the configured model the selected screen context while excluding FoneClaw's own overlays. This prevents the floating controls from becoming part of the attached task input. The model interprets the request, and governed Android tools carry out supported actions through the phone's current permissions and approval state.

Continuity matters when the task changes state. A supported action may be executing, waiting for approval, blocked by a missing permission, or ready to stop. The compact panel keeps those controls available after the user returns Home. Permission recovery can guide the user through the required Android setting and reconnect them with the waiting task. Current FoneClaw release information brings these paths together in the current floating-assistant experience.

The currently available task model provides the underlying independent task states, session-bound approvals, and task isolation. Together, these capabilities demonstrate a state-preserving interface change on one phone: one task identity, one Android execution owner, and several ways to observe or control it. That same discipline is useful when evaluating future cross-device designs, even though cross-device transfer requires additional identity, transport, freshness, and revocation controls.

Test a Secure Agent Handoff

Use a reversible task for the first test. A development example might ask a source CLI session to inspect a project and prepare a summary without committing changes. A phone-agent example might open a supported settings page or prepare a draft without sending it. Record the execution owner before introducing another interface.

1. Start: Confirm the session identity, user, source environment, bounded intent, inputs, and stop condition.
2. Steer: Open the second interface and send one harmless instruction. Verify that it reaches the same task in the correct order.
3. Approve: Trigger a reviewable action. Check that the approval names the task, target, consequence, and device that will execute.
4. Stop: Stop the task remotely and confirm that the execution owner reports a terminal state rather than continuing unseen.
5. Reconnect: Repeat the test with a temporary network interruption. Confirm queued input order, stale-state detection, and expired-token behavior.
6. Audit: Review the origin, steering commands, approvals, denials, tool results, errors, and final outcome.
7. Delete: End the session and remove its remote access or retained state through the documented controls. Confirm that an old link or token cannot reopen it.

Tool discovery also affects the contract. A receiving agent needs to know which capabilities are current, trusted, and authorized before it can resume a task. Agentic Resource Discovery: ai-catalog.json, Tool Trust, and Phone Agent Authorization covers that adjacent question.

A secure cross-device AI agent handoff passes when the user can always answer five questions: where is the task running, what state is current, what can this interface control, which action needs approval, and how can the task be stopped or recovered? Seamless presentation is useful, but trustworthy continuity comes from explicit state and verifiable control.