Harness Notes
AboutJSON

Remote access

Updated 2026-10-21

On this page

Connect

TaskCodexCodex 0.163.0Claude CodeClaude Code latest 2.1.303; stable 2.1.292Cursor Agentpublished 2026.10.16-e3cb207; local ACP probe 2026.10.12-d47ca18OpenCodeOpenCode 2.0.32piPi coding agent 1.3.0
Start the server
App Server launch command
codex app-server --listen ws://127.0.0.1:4500
DocsSource
No inbound listener
outbound HTTPS
Docs
agent acp
stdio; Cloud Agents API
HTTPS beta
Docs
opencode service start
foreground: opencode serve
DocsSource
pi --mode rpc
JSONL stdin/stdout
DocsSource
Connect a client
CLI client command
codex --remote ws://127.0.0.1:4500
SSH forward
DocsSource
Claude web, mobile or desktop
same account
Docs
ACP editor client or Cloud Agents API client
Docs
opencode --server <url>
DocsSource
Your bridge or supervisor
DocsSource
Credentials
App Server listener
Non-loopback requires --ws-auth; unauthenticated listeners refused
Source
claude.ai login
API keys not supported
Docs
CLI login, CURSOR_API_KEY or CLI auth token
worker auth separate
Docs
CLI server: generated password
signed session credentials also accepted
DocsSource
Bridge must authenticate clients
model credentials do not
DocsSource
Connection security
App Server connection
TLS or SSH/VPN
client tokens require WSS or loopback
Source
Workspace trust
optional Trusted Devices
Docs
Credentials authorize service access
no local TCP listener established
Docs
Password rotation revokes sessions
embedded servers may omit password
DocsSource
Bridge must control workspace access
DocsSource
Relay or tunnel
Remote Control CLI
codex remote-control
Source
claude remote-control
claude --remote-control
/remote-control
Docs
My Machines: agent worker start
Docs
opencode pair --remote
encrypted OpenTunnel
DocsSource
Not established in core RPC
hosts/extensions may add one
DocsSource
Pair a device
Remote Control CLI
codex remote-control pair
short-lived code
Source
Pairing command not established
Docs
Registers a tool-execution worker
Docs
Interactive consent or --yes
consent remembered
DocsSource
Not established in core RPC
DocsSource
Requirements
Remote Control service
ChatGPT login
no API keys
managed policy and device enrollment
Source
Pro, Max, Team or Enterprise
team owner approval
no third-party providers, custom base URL or enterprise gateway
Docs
Cloud agent loop
worker must stay connected
Docs
Access to your server
execution stays on its host
DocsSource
Core RPC is a subprocess
remote access needs a bridge
DocsSource
Run in background
Remote Control daemon
Managed daemon when eligible
--no-daemon for foreground
shared daemon environment
DocsSource
Keep local process or Remote Control server running
Docs
Worker reusable across Cloud Agent sessions
Docs
Shared background service
DocsSource
Keep owning and draining RPC child
DocsSource

Cloud tasks

TaskCodexCodex 0.163.0Claude CodeClaude Code latest 2.1.303; stable 2.1.292Cursor Agentpublished 2026.10.16-e3cb207; local ACP probe 2026.10.12-d47ca18OpenCodeOpenCode 2.0.32piPi coding agent 1.3.0
Send to cloud
Cloud CLI
codex cloud exec
DocsSource
claude --cloud
separate cloud session
Docs
Prefix CLI message with &
/in-cloud for subagent
Docs
Provider cloud handoff not established
Docs
Provider cloud handoff not established
DocsSource
Bring work back
Cloud CLI
codex cloud apply
task diff only
DocsSource
--teleport
cloud conversation to terminal
Docs
&: continue on cursor.com/agents
/in-cloud: returns to parent
Docs
Not established
Docs
Not established
DocsSource

Sessions

TaskCodexCodex 0.163.0Claude CodeClaude Code latest 2.1.303; stable 2.1.292Cursor Agentpublished 2026.10.16-e3cb207; local ACP probe 2026.10.12-d47ca18OpenCodeOpenCode 2.0.32piPi coding agent 1.3.0
List sessions
App Server RPC
thread/list
thread/loaded/list for running threads
DocsSource
Registered Remote Control sessions
not all local transcripts
Docs
ACP session/list advertised in 2026.10.12 probe
Docs
HTTP session list/get
Source
Session discovery belongs to SDK/host or session manager
DocsSource
Read history
App Server RPC
thread/read
paginated turns/items
DocsSource
Provider clients
local history is separate
Docs
ACP-owned history
separate ~/.cursor/acp-sessions/ store
Docs
HTTP messages and snapshots
Source
get_messages
get_session_entries
entry cursors
DocsSource
Resume
App Server RPC
thread/resume
DocsSource
--continue or --session-id in server mode
Docs
session/load
terminal history compatibility not established
Docs
Continue server-owned session
ACP resume also available
Source
switch_session
loads in this runtime
DocsSource
Fork
App Server RPC
thread/fork
DocsSource
Not established by this Remote Control audit
Docs
Not advertised in 2026.10.12 ACP probe
Docs
Session fork
conversation copy only
Source
fork
DocsSource
Join running work
App Server
Same App Server thread
multiple subscribed clients
DocsSource
Enabled local conversation
second terminal needs explicit transfer
Docs
Active cloud runs stream
attachment to another local CLI not established
Docs
Multiple UI/API clients
same server sessions
Source
No attachment to another running Pi process through session switching
DocsSource
Answer approvals
App Server protocol
Server approval requests
DocsSource
Provider clients answer tool permission prompts
Docs
ACP: allow once, allow always, reject once
Docs
HTTP permission/form handling
ACP permission decisions
Source
Extension dialogs
no universal built-in approval policy
DocsSource
Receive updates
App Server protocol
Server events
DocsSource
HTTPS streaming
Docs
ACP session/update
Cloud API SSE
Docs
Server event stream
Source
RPC events
agent_settled signals completion
DocsSource
Stop a turn
App Server RPC
turn/interrupt
DocsSource
Provider client controls
no public cancellation API documented
Docs
ACP session/cancel
Cloud API cancellation is separate
Docs
/api/session/:sessionID/interrupt
ACP session/cancel
Source
abort
DocsSource

Execution

TaskCodexCodex 0.163.0Claude CodeClaude Code latest 2.1.303; stable 2.1.292Cursor Agentpublished 2026.10.16-e3cb207; local ACP probe 2026.10.12-d47ca18OpenCodeOpenCode 2.0.32piPi coding agent 1.3.0
When the client disconnects
Remote Control daemon
Daemon stays running
foreground needs its process
DocsSource
Browser may close
execution process must remain running
Docs
Cloud tasks outlive submitting terminal
ACP child needs its client/supervisor
Docs
Background service survives viewer closing
DocsSource
Closing stdin shuts down child
unread stdout can stall it
DocsSource
Restart and recovery
Remote Control daemon
Stop, restart or updates may interrupt work
60s shutdown grace
DocsSource
Server-mode sessions restorable for about 4 hours after stopping
Docs
My Machines requires running worker
Docs
Restart recovery exists
in-flight tools may be interrupted
DocsSource
Separate experimental @earendil-works/pi-durable
storage/task recovery
DocsSource
Where tools run
App Server and desktop SSH
App Server: server host
Desktop SSH project: SSH host
Docs
Remote Control: local host
cloud mode: cloud environment
Docs
Cloud by default
My Machines tools on worker
ACP on local host
Docs
Server host and selected workspace
Docs
RPC host working directory and session files
DocsSource

Build an integration

TaskCodexCodex 0.163.0Claude CodeClaude Code latest 2.1.303; stable 2.1.292Cursor Agentpublished 2026.10.16-e3cb207; local ACP probe 2026.10.12-d47ca18OpenCodeOpenCode 2.0.32piPi coding agent 1.3.0
ACP
Community ACP adapter
Community @agentclientprotocol/codex-acp
stdio
DocsSourceEvidence
Separate @zed-industries/claude-agent-acp
stdio
SourceEvidence
Native agent acp / cursor-agent acp
stdio
Docs
Native ACP
stdio
separate from HTTP and OpenTunnel
DocsSource
Community pi-acp
separate from core RPC
DocsSource
API or SDK
App Server protocol
App Server JSON-RPC
DocsSource
Agent SDK
separate from Remote Control
Docs
ACP for editors
Cloud Agents API for cloud runs
Docs
Native HTTP API/client
Source
Pi Durable adds recovery
no network/pairing interface established
DocsSource
Custom relay clients
Hosted Remote Control relay
No supported public custom-client relay API established
Source
No public custom-client protocol documented
Docs
Local CLI network attachment not established
Docs
Use HTTP API
check embedded server auth separately
Source
Bridge or extension behavior must be checked separately
DocsSource

Research and evidence

Codex CLI, Source inspected, Remote execution not tested
  • App Server and daemon remain experimental; account, managed policy and client rollout can gate relay use.
  • Direct listener authentication and provider-relay enrollment are separate.
  • Hosted relay internals, cross-device rollout and end-to-end pairing were not runtime verified.
  • Source inspection and official documentation establish implementation or documented behavior, not a passing end-to-end remote probe.
  • connect: Run codex app-server --listen ws://127.0.0.1:4500 on the execution host and codex --remote ws://127.0.0.1:4500 through an SSH forward. App Server also has stdio and local Unix-socket transports; these carry its own JSON-RPC protocol, not ACP.
  • auth: At 0.163.0 an unauthenticated non-loopback WebSocket listener is refused. Configure --ws-auth capability-token or --ws-auth signed-bearer-token; supply client credentials through --remote-auth-token-env. Use TLS termination or an SSH/VPN boundary for network traffic. This replaces the August rollout claim that unauthenticated non-loopback listeners were allowed.
  • The client rejects sending remote auth tokens over non-loopback plain ws://; use wss:// or loopback ws:// through a secure forward. Listener TLS termination is separate from the listener itself.
  • relay: codex remote-control enables provider-relayed access to a host App Server. start, stop and pair are separate subcommands; pairing creates a short-lived manual code. Default invocation uses a managed daemon when eligible and otherwise a foreground server; --no-daemon forces foreground. This is a managed-device relay path, not documentation of a public custom-client relay API. App Server also registers remoteControl enable/disable/status, pairing start/status, and paired-client list/revoke RPCs; those control-plane methods do not make the hosted relay a supported public transport for arbitrary clients.
  • Relay authentication requires ChatGPT account credentials; API-key authentication is rejected. Managed allow_remote_control requirements and host/client enrollment still apply.
  • cloud: codex cloud exec submits a task to a provider cloud environment; codex cloud apply applies an attempt's diff locally. This is a cloud task/diff workflow, not attachment to the original local process or full conversation teleport. Desktop SSH projects are another host choice, with execution on the SSH host.
  • history: App Server separates stored thread/list from in-memory thread/loaded/list. thread/read reads metadata; paginated turns/items load history. thread/resume reopens or attaches a thread for subsequent turns and subscribes to events; thread/fork creates a new thread from stored history. Listing or reading history alone does not attach to active work.
  • attach: Clients can subscribe to a thread already loaded in the same App Server. A live attachment shares that server-owned thread; resuming a historical rollout in another process is a separate operation. Disconnect removes connection bookkeeping rather than automatically shutting down every loaded thread.
  • controls: Clients receive server-initiated approval requests and streamed events. Use turn/interrupt for turn cancellation; unsubscribing or dropping the connection is a separate action. Pending connection-scoped requests and command-execution resources have their own disconnect cleanup.
  • lifetime: The managed daemon is detached from an individual TUI; leaving that client does not stop the daemon. remote-control --no-daemon belongs to the foreground process. Explicit stop, restart and eligible automatic updates can interrupt active or queued work; shutdown grace defaults to 60 seconds. Shared clients inherit the daemon environment, without per-client environment isolation.
  • workspace: Repository files and shell execution belong to the selected local or SSH host. The viewing phone or desktop does not acquire its own copy of the workspace through attachment. App-specific host support, account access and connectivity remain separate from the open-source transport.
  • acp: Codex ACP uses the community @agentclientprotocol/codex-acp adapter over stdio, which drives App Server. Native App Server network connectivity does not make Codex a native ACP server.
  • ACP adapter research retains its 2026-10-15 version boundary; this remote refresh is not a new adapter runtime probe.
  • embedding: App Server is the custom-client integration surface. CLI dispatch constructs the runtime, selects a listener, applies managed remote-control policy, and starts transport handling. The hosted relay service and desktop/mobile clients are outside this source audit; matching RPC names do not prove a supported third-party relay protocol.
Claude Code, Documentation, Remote execution not tested
  • Closed-source CLI and hosted relay behavior here is documentation evidence, not inspected implementation.
  • Latest and stable package versions differ; documentation can describe rollout beyond an installed client.
  • No eligible-account Remote Control pairing, cloud provisioning, SDK turn or current ACP adapter probe was run.
  • Source inspection and official documentation establish implementation or documented behavior, not a passing end-to-end remote probe.
  • 2.1.304 published fixes: desktop history recovers after a terminal account mismatch; Desktop Remote Control starts on paid plans with DISABLE_TELEMETRY/DO_NOT_TRACK; SDK/desktop model switches, messages and interrupts no longer wait behind context-usage checks. No remote runtime probe performed.
  • connect: Remote Control registers a local session with Anthropic and uses outbound HTTPS and streaming delivery; it opens no inbound listener. A custom-client network server is not established by this provider-client workflow.
  • auth: Remote Control requires claude.ai login and a Pro, Max, Team or Enterprise subscription; API keys are not supported. Team/Enterprise owners enable it. Bedrock, Google Cloud Agent Platform, Microsoft Foundry, custom ANTHROPIC_BASE_URL and enterprise Claude apps gateways are excluded. Feature-flag settings, workspace trust and optional Trusted Devices can block access.
  • relay: Use claude remote-control server mode, claude --remote-control, or /remote-control in an existing conversation. Same-account Claude web/mobile/desktop clients can view and steer Remote Control-enabled sessions. remoteControlAtStartup can auto-enable interactive processes; it does not publish every historical local session.
  • cloud: claude --cloud creates a separate cloud session; its deprecated alias --remote is unrelated to --remote-control. --teleport pulls a cloud conversation back to the terminal. The cloud repository snapshot and the local checkout have different filesystem lifetimes.
  • history: Provider clients discover registered Remote Control sessions. Local --continue/--resume and cloud teleport are different history paths. Server mode can restore its served sessions for about four hours after stopping; --continue or --session-id selects one. This is not a generic network API for arbitrary local transcript enumeration.
  • attach: An enabled session is the live local conversation seen from terminal and provider clients. Resuming the conversation in a second terminal leaves Remote Control with the first process; explicit /remote-control transfers it. Historical resume is not proof that two processes attach to one live runtime.
  • controls: Connected provider clients can send messages and respond to tool permission prompts. CLI permission policy still governs execution. Control and stop actions belong to those clients; a public custom-client cancellation protocol is not documented by Remote Control.
  • lifetime: Execution requires the local process or Remote Control server to remain running. Network drops can reconnect, and server-mode records permit a bounded restart window. Closing the browser is distinct from stopping the execution process; a saved transcript is not a running worker.
  • workspace: Remote Control reads files, runs tools and uses local MCP/configuration on the execution machine. Transcript content is stored on Anthropic servers for synchronization. Cloud mode instead executes in its cloud environment; teleport does not transfer a running process.
  • acp: Claude Code ACP uses the separate @zed-industries/claude-agent-acp adapter and Agent SDK over stdio. Remote Control and cloud session synchronization are not ACP transports.
  • ACP adapter research retains its 2026-10-15 version boundary; this remote refresh is not a new adapter runtime probe.
  • embedding: Agent SDK embeds the Claude Code engine for an application with its own process, streaming, permissions and session handling. Hosting that application remotely is a separate integration from provider Remote Control. Its session resume/fork APIs do not establish access to an already running terminal process.
Cursor Agent, Documentation, Remote execution not tested
  • Closed-source Cursor implementation and hosted services are documented boundaries.
  • My Machines is a distinct self-hosted tool-execution layer; worker availability and authentication are account dependent.
  • No 2026.10.16 runtime probe, session list/load, cloud handoff, worker enrollment or model-turn probe was run.
  • Source inspection and official documentation establish implementation or documented behavior, not a passing end-to-end remote probe.
  • connect: Native agent acp uses JSON-RPC over stdio. Separately, the public beta Cloud Agents HTTPS API lets custom clients create and manage cloud agents and runs. This does not establish a network API for attaching to an arbitrary running local CLI.
  • auth: ACP advertises cursor_login; pre-authentication can use CLI login, CURSOR_API_KEY or CLI auth-token paths. These authorize Cursor service access, not a new TCP listener. My Machines workers separately authenticate the user or supported token path.
  • The Cloud Agents public beta API separately accepts Basic or Bearer authentication with a user or service-account API key. ACP login, worker enrollment and Cloud API credentials authorize different interfaces.
  • relay: My Machines runs agent worker start with an outbound connection to Cursor. The agent loop is in Cursor cloud and tool calls execute on the registered machine. This is a cloud worker integration, not a relay into an existing interactive CLI conversation.
  • cloud: Prefix a CLI message with & to hand the conversation to a Cloud Agent and continue on cursor.com/agents. A cloud subagent (/in-cloud) is a separate delegation path that returns to its parent; neither implies live attachment to the original CLI process.
  • history: Native ACP documents session/new and session/load. The local 2026.10.12 initialize probe advertises loadSession and session/list, but not resume or fork. The retained October 15 ACP audit records a separate ~/.cursor/acp-sessions/ store: do not promise terminal agent --resume chats are loadable through ACP. CLI history and cloud task history remain separate surfaces.
  • Initialization only confirms advertised capability; no session list/load or model request was sent in this refresh. Store interoperability retains the earlier binary audit boundary.
  • The Cloud API separately lists agents and runs; its run SSE stream is not replay of prior runs. It does not establish local ACP/terminal store interoperability.
  • attach: The Cloud API can stream an active cloud run; this is distinct from ACP session/load reopening an ACP-owned conversation. Neither the docs nor initialization probe establish attachment to a separately running local terminal agent.
  • controls: ACP uses session/request_permission with allow-once, allow-always or reject-once, streamed session/update and session/cancel. Those stdio methods do not define the Cloud Agent or worker wire protocol.
  • The Cloud API has per-run SSE streaming and cancel. Cancelled runs cannot resume; continuing the conversation creates a new run on the same agent. This is separate from ACP session/cancel.
  • lifetime: Keep the My Machines worker process running; it is reusable across Cloud Agent sessions until stopped. An ACP client owns its spawned stdio process unless it adds a supervisor. Cloud tasks have a provider-managed lifetime independent of the terminal used to submit them.
  • workspace: Ordinary Cloud Agents execute in provider cloud environments. My Machines keeps the agent loop in cloud but runs shell, file edits, browser actions and tools on the worker machine. Native local ACP runs with the spawned agent's working directory. These execution locations must not be conflated.
  • acp: Cursor has a native ACP command: agent acp / cursor-agent acp. It uses stdio, initialize/authenticate, session new/load, prompt updates and cancellation. Native ACP is an editor integration, not evidence of network attachment.
  • embedding: Use ACP for custom editor clients. The separate public beta Cloud Agents API supports agent/run creation, listing, SSE and cancellation; My Machines registers tool-execution workers. These cloud interfaces do not establish custom-client attachment to a live local CLI.
OpenCode, Source inspected, Remote execution not tested
  • Default password and pairing behavior applies to the released 2.x CLI-managed service, not all embeddings.
  • OpenTunnel exposure needs consent and a running server; OpenCode 1.x has separate historical behavior.
  • No OpenTunnel provisioning, device pairing, permission turn or restart recovery probe was run.
  • Source inspection and official documentation establish implementation or documented behavior, not a passing end-to-end remote probe.
  • connect: opencode service start runs the shared background HTTP server and web UI; opencode serve runs it in the foreground. Connect a TUI with opencode --server <url>. Default loopback ports are 49374 on macOS/Linux/WSL and 45278 on Windows; use service status for the actual address.
  • auth: The CLI-managed server generates password protection by default. HTTP authorization accepts the server password or a signed session credential, including paired browser cookies. Password rotation invalidates all issued sessions. The lower-level server auth Config can omit a password: do not infer that every custom embedded server is protected.
  • Pairing codes are single-use with a five-minute TTL; resulting credentials last 30 days. Listen address, CORS and authentication are separate settings.
  • relay: opencode pair --remote exposes the server through an end-to-end encrypted OpenTunnel address. Initial exposure requires interactive consent or --yes; acceptance is remembered. Pairing grants access to this server, while execution stays on its host. This tunnel is distinct from provider cloud task handoff.
  • cloud: The native service and OpenTunnel connect clients to your execution host. They do not establish a provider-hosted Cloud Agent conversation handoff or teleport workflow. No such handoff is inferred from server availability.
  • history: The HTTP API has session list/get and message/snapshot operations plus session fork. Clients can read stored history and continue server-owned sessions. ACP separately registers list/load/resume/fork; load replays history while resume can attach without that replay. A copied fork is a distinct conversation, not a filesystem snapshot.
  • attach: Multiple UI/API clients talk to the same running server and its sessions. Event streaming gives live updates; reopening persisted history is separate from watching an active session. The native HTTP routes and ACP session methods are different protocols.
  • controls: The native HTTP API exposes session.interrupt at /api/session/:sessionID/interrupt, along with permission/form handling. ACP translates permission decisions and session/cancel to server control operations. Disconnecting a viewer is distinct from explicitly interrupting execution; cancelling queued input is another operation.
  • lifetime: The shared background service survives an individual TUI or browser closing. Foreground serve lasts with its process or supervisor. Service configuration changes stop the background server and need a subsequent start. Restart recovery exists, but uninterrupted in-flight tools across server death are not guaranteed.
  • workspace: Files, shell tools, configuration and session state belong to the OpenCode server host and selected workspace. Pairing a phone or opening a remote TUI does not move execution to that client.
  • acp: Native OpenCode ACP runs over stdio, with list/load/resume/fork and cancellation registered as separate protocol handlers. It drives the OpenCode service through its client; the stdio endpoint is not itself the HTTP API or an OpenTunnel URL.
  • embedding: Use the native HTTP API/client for custom remote interfaces and event streams. The server auth module, middleware and CLI launch/configuration path must be considered together; a password default in the CLI is not a universal framework guarantee.
pi, Source inspected, Remote execution not tested
  • Claims about absent network framing are scoped to the inspected core RPC path, not community extensions or custom embeddings.
  • Pi Durable is a separate experimental package with a distinct API and storage/lifetime model.
  • No remote bridge, community adapter turn, process-death recovery or Pi Durable runtime probe was run.
  • Source inspection and official documentation establish implementation or documented behavior, not a passing end-to-end remote probe.
  • connect: pi --mode rpc is a long-lived subprocess controlled through JSONL stdin/stdout. A remote deployment needs an application-owned bridge or supervisor. The audited core RPC entry path supplies no network listener or network authentication contract; extension-built servers are outside that claim.
  • auth: Core RPC uses the spawned process boundary. Provider credentials authenticate model access; they do not authenticate remote bridge clients. A hosting application must define transport authentication and workspace access control.
  • relay: The core RPC contract documents local pipes, not a provider-managed device pairing or relay service. Community extensions or remote hosts may add such a layer; their behavior is not inherited from Pi RPC.
  • cloud: Running Pi on a remote host is a deployment choice. A provider-hosted cloud handoff/teleport workflow is not established by the coding-agent RPC or durable library.
  • history: RPC supports switch_session, fork, get_messages, and get_session_entries for stored session state and history. Entry cursors can recover appended records across client restarts. Session file discovery belongs to the SDK/host or session manager rather than being inferred from a remote session-list endpoint.
  • attach: Switching a session loads it in this RPC runtime; it does not attach to another running Pi process. A bridge must manage routing, process ownership and replay. Pi Durable storage recovery is a separate harness model.
  • controls: RPC has explicit abort, streamed events and extension UI requests/responses. Supported extension dialogs are not a universal built-in approval policy. Read stdout continuously; success of a prompt command is not completion of its model run. agent_settled is the completion signal described by the current contract.
  • lifetime: The RPC child belongs to its spawning client. Closing stdin requests orderly shutdown and runtime disposal; stopping stdout consumption can stall the process. For disconnection tolerance, a bridge must keep owning and draining the child. Durable restart recovery is not implicit in RPC.
  • workspace: The process runs against its selected working directory and session files on the host. A remote viewer cannot assume its own filesystem is available to tools.
  • acp: Pi ACP is provided by the community pi-acp adapter, not the core stdio RPC protocol. Other SDK-based adapters have separate behavior. The retained ACP contract must be consulted for adapter-specific history and approval limits.
  • ACP adapter research retains its 2026-10-15 version boundary; this remote refresh is not a new adapter runtime probe.
  • embedding: @earendil-works/pi-durable is a distinct experimental durable harness built on pi-ai and Chord. It checkpoints conversations and tasks to storage so reopening can recover work. Cancelling a wait does not cancel the work. This contract establishes storage/task recovery, not a network or device-pairing interface; remote hosts must define those layers separately.