A lost stream is not a failed task
If the browser or server loses its stream, retain the session ID and inspect current state and saved items. Do not create another session solely because the connection closed. Your application should distinguish receiving progress from the agent actually making progress.
Connection waits need compatible timeouts
The documented input-time environment connection wait is up to five minutes. Configure the client and proxy accordingly, or use a background-job interface that does not require the browser request to stay open. A connection arriving after timeout does not replay the failed input.
Retry the right unit
Application-side policy: use bounded backoff with jitter for retryable transport or service failures, but reconcile session state before resubmitting work. Authentication failures need credential correction. Tool validation failures need corrected arguments. Unknown outcomes for external writes need reconciliation with the target service, not blind repetition.
Make business writes idempotent
Store a job ID, session ID, tool-call reference, and stable business-operation key. Where supported, pass that operation key to the downstream service. If a write times out, query the downstream operation before attempting it again. Webhook deduplication alone cannot prevent a model from requesting the same business action twice.
Check results, not only status
A mid-turn executor disconnect can fail a command even when the turn completes. Inspect tool errors, final output, and expected artifacts. After a process crash, the API does not guarantee pending-input recovery. Preserve evidence and offer an explicit retry or escalation path when the outcome remains uncertain.
Read the official reference
Check the source for current API fields, account requirements, and service limits.
OpenAI: lifecycle