feat: Add E2B-compatible volume management APIs

[AiRanthem]

Background

E2B Python SDK 2.25.0 exposes volume management through platform API calls. The SDK uses /volumes for create/list and /volumes/{volumeID} for get/delete.

sandbox-manager currently has no /volumes routes. POST /sandboxes also does not model the SDK's volume_mounts request field.

Issue Type

Feature request

Relevant Code

• pkg/servers/e2b/routes.go does not register /volumes or /volumes/{volumeID} routes.
• pkg/servers/e2b/models/sandbox.go defines NewSandboxRequest without a volumeMounts / volume_mounts field.
• pkg/sandbox-manager/infra/sandboxcr/claim.go and pkg/sandbox-manager/infra/sandboxcr/clone.go contain CSI mount handling used by current extension-based mount behavior.

Notes

Related E2B-compatible surface includes:

• GET /volumes
• POST /volumes
• GET /volumes/{volumeID}
• DELETE /volumes/{volumeID}
• sandbox create volume mount request compatibility.

[kavyarathod05]

@AiRanthem can you assign this to me ?

[AiRanthem]

@kavyarathod05 Welcome!

Could you first put together a proposal/design document for this feature?

This is a fairly large feature and we don't yet have a clear implementation direction. Before diving into the implementation, it would be helpful to have a proposal that covers, for example:

• Problem statement and motivation
• Goals and non-goals
• High-level design
• API and data model changes
• State transitions and compatibility considerations
• Migration strategy for existing objects
• Failure scenarios and edge cases
• Rollout plan
• Alternatives considered and trade-offs

Having the design documented first will make it easier for everyone to review the approach, align on the expected behavior, and identify potential issues before implementation begins.

[princexpoddar]

Hi @AiRanthem,

I was interested in this issue and put together a proposal covering the requested design areas. The approach aims to add E2B-compatible volume management while reusing the existing CSI/PV infrastructure.

I'd appreciate any feedback on the proposed direction. If the approach looks reasonable, I'd be happy to work on the implementation as well.

Proposal: https://github.com/princexpoddar/agents/blob/master/docs/proposals/e2b-volume-management.md

[furykerry]

I'd appreciate any feedback on the proposed direction. If the approach looks reasonable, I'd be happy to work on the implementation as well.

Proposal: https://github.com/princexpoddar/agents/blob/master/docs/proposals/e2b-volume-management.md

@princexpoddar i think new CRD for sandoxvolume is not necessary, just use PV object to implement volume api.

[princexpoddar]

@princexpoddar i think new CRD for sandoxvolume is not necessary, just use PV object to implement volume api.

@furykerry Thanks for the feedback. I reworked the proposal to remove the SandboxVolume CRD and use existing Kubernetes PV objects directly.

Proposal: https://github.com/princexpoddar/agents/blob/master/docs/proposals/2026-06-07-e2b-volume-management.md

The updated approach treats registered PVs as volumes, stores the required volume metadata on the PV itself, and reuses the existing CSI mount pipeline for volume_mounts. This avoids introducing a new CRD or controller while keeping the implementation aligned with existing Kubernetes storage primitives.

I've started working on the implementation based on this approach. If this looks good, could you please assign the issue to me?

[ZhaoQing7892]

@furykerry