Test session continuity across a hosted agent harness and a self-hosted executor

A successful follow-up response does not, by itself, prove session continuity. The response could come from the original executor, a replacement with restored state, or a replacement with no retained application state. It could also arrive only after a retry that the application never exposes.

That ambiguity matters in the runtime model described by two recent announcements. OpenAI assigns the hosted harness, sessions, orchestration, context compaction, and recovery to the Agents API while allowing compute to run in an OpenAI-managed sandbox, developer infrastructure, or a sandbox partner (OpenAI). Cloudflare’s reference implementation maintains one Cloudflare Container for each Codex session, reconnects when follow-up input arrives, and shuts the container down when idle (Cloudflare). Neither document establishes what a particular deployment will preserve through an interruption.

The useful test, then, is not simply “did the session recover?” It is an attempt to rule out competing explanations for what happened.

Four explanations for the next response

Before injecting a failure, define the outcomes that the observations must distinguish:

• The same executor returns with the test state intact.
• A replacement executor restores the test state.
• A replacement executor handles the request without the test state.
• No executor completes the request because it fails, times out, or remains pending.

These outcomes require three correlated values: the hosted session identifier, the executor or container identifier, and a harmless state marker. A generated nonce, counter, or temporary file can serve as the marker when its persistence location is known. It is instrumentation for one state path, not evidence that every kind of application state will survive.

Record those values with timestamps when the session begins, immediately before interruption, when follow-up input arrives, and after the system settles. Preserve the harness and executor configurations used in the run. Retry or recovery events and the measured transition time belong beside those records. The timing is a result from the evaluated configuration, not a platform guarantee.

Try to disprove the strongest outcome

Create the marker and confirm that the executor can read it. Then interrupt only the self-hosted executor while keeping the hosted session available. Send follow-up input through that same session.

The strongest interpretation—same executor, same state—survives only if both identity and marker checks agree. If the identifier changes but the marker remains, the observation instead points to replacement plus some restoration mechanism. If a response arrives without the marker, request progress occurred without demonstrated state continuity. A timeout or pending request is a separate result and should remain labeled as such.

Repeat the interruption before executor work begins, during work, and after work completes but before the next input. This is an SGL testing judgment, not behavior specified by either announcement. The purpose is to expose whether the interruption point changes which explanation fits; it is not to generalize from a few runs to every in-flight transition.

Use idleness as a second cause, not a second test plan

An injected interruption and an idle shutdown may produce similar visible symptoms while following different runtime paths. Cloudflare documents idle container shutdown and reconnection on follow-up input for its reference implementation (Cloudflare). In the evaluated configuration, stop sending input and timestamp when the executor becomes unavailable. Then send follow-up input through the existing hosted session.

Apply the same four explanations again. Check whether the session remains addressable, whether an executor becomes available, whether its identifier changed, and whether the marker survived. Reusing the same interpretation scheme makes the two causes comparable without assuming that deliberate interruption and idle shutdown share a recovery mechanism.

A final clean-start check addresses the opposite risk: unwanted continuity. Allow the existing session and executor to reach their intended terminal conditions, start a new session, and verify that it receives a new session identity. The prior marker should not appear unless the application deliberately uses shared persistence. One passing run may expose or fail to expose carryover; it cannot establish isolation across every workload and failure mode.

Report ambiguity instead of compressing it

For each event, place the provider-documented behavior beside the local observation. The documentation side contains the relevant source claim. The observation side contains identifiers, timestamps, logs, marker checks, configuration, and measured timing. This keeps a public-beta announcement or reference implementation from becoming operating evidence by implication.

The practical question for teams building agent systems is narrower than whether the runtime “recovers.” After interruption or idleness, which of the four explanations remains consistent with the evidence? If the records cannot distinguish them, the run has found an observability gap rather than continuity.