Use the approved policy for each sandbox start, retry, and recovery #5109

User Story

I stop a sandbox, update its policy and start it again. For a sandbox with a live policy, I need that start to use the newly approved revision and keep the same input through retries and gateway recovery. A frozen sandbox must keep its original snapshot and reject policy changes.

Problem Statement

StartSandbox sends a launch generation and credentials, but no current approved policy document. A retained compute resource can therefore start with its creation-time policy while the supervisor receives a newer revision.

The two sides can disagree about the permissions for the same launch. Fetching a different policy on each retry would also make that launch's inputs unstable.

Impact / Why This Matters

Users may need to recreate a sandbox to change static permissions, or encounter a safe backend refusal after stop/update/start. Falling back to an older, broader policy would undo the user's requested restriction.

Each launch needs one committed policy input that retries and recovery reuse. The existing frozen-policy rules must continue to take precedence.

Proposed Design

For a live sandbox, capture the current admitted policy atomically with the runtime generation claim. Send its bounded document, digest and generation to capable compute drivers. Retried and recovered starts reuse that input. Permit static changes while stopped for negotiated drivers, preserve restrictions on live static changes, and keep network reload separate from immutable launch identity.

Frozen policy takes precedence: use the existing frozen snapshot and digest for a frozen sandbox on every start, retry and recovery. Reject frozen policy mutations; allow a fresh capture only for live sandboxes.

Example workflow for review: For a live sandbox, stop, update policy, then start with the new admitted revision. For a frozen sandbox, the policy update is rejected and every restart retains the original frozen snapshot and digest.

Acceptance Criteria

• For a live sandbox, stop/update/start uses the newly admitted static policy.
• A same-generation retry and gateway recovery retain the exact committed input.
• Malformed hashes, stale inputs and unsupported changes fail before replacing runtime resources.
• A narrowing never falls back to an older policy.
• Frozen starts, retries and recovery retain their original snapshot; frozen policy mutation is rejected.

Alternatives Considered

Recreation is safe but disrupts retained workspaces. Fetching the latest policy independently during every retry does not preserve launch identity. Providers, middleware and interceptors cannot atomically own a compute lifecycle claim.

Reconcile with frozen policy in PR #4735 before publication. Frozen sandboxes must retain their creation snapshot and digest on start/retry/recovery and reject policy mutation; only live sandboxes may capture a new admitted policy. Combined frozen/live verification is still required.

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request