Two lifecycles, two owners
A durable session can outlive its compute. With a self-hosted environment, your application owns provisioning and file persistence while OpenAI operates the harness. Store the session-to-provider mapping and appoint one controller to manage it, so concurrent notifications cannot create duplicate machines.
Start on the correct signal
An environment_connection required action can trigger startup or reconnection. Verify the webhook, durably queue the work, and retrieve the latest session before provisioning. A function_call action requires a tool result instead. An in_progress notification is too late to be the initial startup trigger for an offline executor.
Reconnect compute without inventing recovery
Use the session's environment ID and remote URL with an environment key for the executor. Reusing an ID does not restore files on replacement compute: provide storage or snapshots yourself. A disconnected command is not automatically restarted, and a completed turn can still contain a failed tool.
Avoid premature shutdown
An idle notification is not enough to stop compute safely. Coordinate incoming work with any grace-period timer and recheck state before shutdown. If your controller cannot coordinate these races, keep compute available between turns.
Delete both resources deliberately
Stop new input and coordinate outstanding startup work. Preserve needed outputs, delete the session, and release provider compute separately. Session deletion neither shuts down the provider environment nor sends a deletion webhook. Test cleanup during concurrent startup, not just after a successful job.
Read the official reference
Check the source for current API fields, account requirements, and service limits.
OpenAI: lifecycle