Background Runs and Streaming
Submit, follow, reconnect to and cancel Claude and Codex runs.
Use the support-agent service from Run Claude or Run Codex. Add the deployment queue configuration before relying on worker recovery.
Start background work with a stream
curl -N http://127.0.0.1:7777/agents/support-agent/runs \
-F 'message=Explain the steps for investigating a delayed order. Do not use tools.' \
-F 'session_id=background-demo' \
-F 'background=true' \
-F 'stream=true'This request returns SSE. Copy the run ID and latest event_index. Closing this client connection does not cancel a background run. Short requests may complete before you disconnect; use a controlled slow tool when testing a genuinely active reconnect.
Reconnect or poll
Set the values from the original stream:
RUN_ID="paste-the-run-id"
LAST_EVENT_INDEX="paste-the-last-received-event-index"
curl -N -X POST "http://127.0.0.1:7777/agents/support-agent/runs/$RUN_ID/resume" \
-F 'session_id=background-demo' \
-F "last_event_index=$LAST_EVENT_INDEX"Use the last received index, not the count of displayed text chunks. With shared Redis coordination, a different API replica can provide retained events. If you received no indexed event, use -1 to request the retained stream from its beginning.
Poll the stored run independently:
curl "http://127.0.0.1:7777/agents/support-agent/runs/$RUN_ID?session_id=background-demo"For Claude and Codex, request streaming at submission if later event catch-up is required. A background request with stream=false returns HTTP 202 and a run ID for polling, but does not establish replayable SSE events. When live transport events expire, /resume can replay retained events from the stored run. AgentOS enables event storage for registered harness agents; RunContent token deltas are skipped by default, so database replay is not a token-for-token copy of the live stream. Use the stored terminal content for the final answer. An unavailable Redis connection is distinct from an expired stream; handle transport errors and poll saved run state when appropriate.
Cancel a run
curl -X POST "http://127.0.0.1:7777/agents/support-agent/runs/$RUN_ID/cancel?session_id=background-demo"For durable queued runs, inspect metadata.queue.final when polling: the queue's settled outcome is distinct from a failed component attempt. See Retries and Tool Effects for retry, pause and unknown-finality handling.
Poll for terminal status after cancellation. Cancellation does not undo tool effects that have already happened. Share Redis coordination to cancel through a replica other than the one executing the run.
Choose the durability policy
background=true separates execution from the client connection. Add QueueConfig(durable=True) for supported requests that must be durably accepted. Share Postgres for storage and Redis for multi-replica coordination.
The default queue max_attempts=1 makes interrupted execution fail visibly without automatic re-execution. Opting into more attempts can repeat external effects. See Durable Queue for queue eligibility, ownership and retry configuration, and Deploy and Operate for the combined service setup.