Problem
The native sandbox_agent mount currently receives a concrete Sandbox Agent baseUrl when the VM is created. That endpoint is not stable across sandbox replacement: Docker allocates a new host port, and hosted providers may return a different URL after recreation or resume. A lazy sandbox that shuts down while the VM remains alive therefore cannot safely reuse the original mount descriptor.
Desired behavior
- Give each AgentOS VM a stable sandbox endpoint for the lifetime of the VM.
- Route that endpoint through a host relay, mutable resolver, or equivalent indirection to the currently active Sandbox Agent client.
- Let both the native filesystem mount and process bindings share the same current client and lazy lifecycle.
- Update authentication headers/tokens when the backing sandbox changes without remounting or rebooting the VM.
- Fail clearly while startup is in progress or has failed; concurrent calls must remain single-flight.
- Add native coverage that accesses the same mounted path before and after replacing the backing sandbox without restarting the AgentOS VM.
Provider sandbox IDs may remain stable for reconnect-capable backends, but their network address must not be treated as a cross-provider invariant.
Problem
The native
sandbox_agentmount currently receives a concrete Sandbox AgentbaseUrlwhen the VM is created. That endpoint is not stable across sandbox replacement: Docker allocates a new host port, and hosted providers may return a different URL after recreation or resume. A lazy sandbox that shuts down while the VM remains alive therefore cannot safely reuse the original mount descriptor.Desired behavior
Provider sandbox IDs may remain stable for reconnect-capable backends, but their network address must not be treated as a cross-provider invariant.