Skypilot sandboxes

[zozo123]

https://blog.skypilot.co/sandboxes/

Deep dive and see if relavnt

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 1, 2026, 2:44 PM ET / 18:44 UTC.

Summary
Keep this open as a help-wanted provider proposal. Current main has no SkyPilot implementation, while the July 17 and July 28, 2026 discussion already sets a concrete contribution boundary: a SkyPilot operator should own an adapter and provide real create/use/destroy evidence with clean teardown.

Reproducibility: not applicable. this is a request for a new optional provider rather than a report of broken current behavior.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
The remaining work requires a committed SkyPilot operator to own ongoing provider maintenance and real remote lifecycle validation, so it is not a bounded automated repair.

Review details

Best possible solution:

Have a SkyPilot user build and maintain an adapter behind Crabbox’s provider-neutral boundary, with documented configuration and redacted live create/use/destroy proof showing clean teardown; a separately versioned adapter using provider: external is also an available starting point.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a request for a new optional provider rather than a report of broken current behavior.

Is this the best way to solve the issue?

Yes, if pursued: an adapter-owned implementation with live lifecycle proof follows the documented provider boundary and the maintainer’s existing acceptance criteria.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A first-class SkyPilot integration without an active SkyPilot operator and real lifecycle proof could leave cross-cloud provisioning or cleanup behavior unverified.

Codex review notes: model internal, reasoning high; reviewed against 0171ae2ee19f.

Label changes

Label changes:

• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P3: This is an optional provider expansion with explicit help-wanted maintainer direction, not a regression in existing execution behavior.
• impact:other: The request affects available remote execution capacity but does not match the specific data, security, delivery, session, or auth impact labels.

Evidence reviewed

What I checked:

• No current SkyPilot provider: A case-insensitive whole-tree search found no SkyPilot implementation or documentation on current main; the requested provider capability is not already shipped. (0171ae2ee19f)
• Existing extension boundary: The external provider is registered as a generic SSH-lease provider, and its documentation states that separately versioned tools may own provisioning, inventory, resume, release, and authentication while Crabbox handles execution and results. (internal/providers/external/provider.go:10, 0171ae2ee19f)
• Vision and repository policy fit: VISION.md and AGENTS.md both require provider-specific lifecycle behavior to remain behind adapters; VISION.md additionally requires real create, use, and destroy proof with zero residue for funded or remote providers. (VISION.md:1, 0171ae2ee19f)
• Maintainer direction: The discussion explicitly keeps this as help wanted: SkyPilot overlaps existing cloud adapters, and a contributor who operates SkyPilot must be prepared to maintain the adapter and show lifecycle proof.
• Provider-boundary provenance: Blame attributes the current external-provider documentation boundary to the commit below by Peter Steinberger; the issue discussion from steipete supplies the matching current acceptance criteria. (docs/providers/external.md:1, 797f20736844)
• Maturity scorecard unavailable: The required maturity helper could not classify this surface because the checked-out repository has no qa/maturity-scores.yaml; no maturity label is selected.

Likely related people:

• steipete: Authored the current issue direction and is the blamed author of the external-provider documentation boundary that a SkyPilot adapter would need to follow. (role: recent provider-boundary contributor; confidence: high; commits: 797f20736844; files: docs/providers/external.md, internal/providers/external/provider.go)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Thanks for the suggestion! Marking this help wanted.

Honest status: Crabbox already supports a good range of providers, and the maintainer is at capacity for adding ones they don't personally use — each provider is an ongoing maintenance and live-proof commitment, not a one-time PR.

That said, this is a genuine invitation: if you (or anyone) have a strong need for this provider and are willing to not just open a PR but also use it regularly and help keep it working, we'd be happy to integrate it. A provider adapter that fits the existing boundaries (core stays provider-neutral; provider-specific lifecycle lives behind the adapter) plus real create/use/destroy proof with clean teardown is very welcome. Comment here if you want to take it on and we'll help.

[steipete]

Maintainer triage note: took a look at SkyPilot Sandboxes for fit. SkyPilot is a multi-cloud orchestration layer, so a SkyPilot provider would largely overlap the existing aws/gcp/azure adapters — the interesting delta is its cross-cloud placement/spot logic, not a new sandbox primitive. Keeping this open as help wanted under the standing provider policy: it needs a contributor who actually runs SkyPilot and will maintain the adapter. Without that, no plans to build it first-party.