e2b: Sandbox.create silently drops volumeMounts

[sweetcornna]

What happened

e2b 2.31.0 supports volumeMounts on Sandbox.create and serializes the requested volume names and mount paths into the create request. Dormice's loose create schema does not model the field, silently ignores it, and launches the sandbox with only an image.

Reproduction:

1. Call Sandbox.create({ ...connection, volumeMounts: { '/mnt/data': 'definitely-missing-volume' } }) through the official SDK.
2. Inspect getInfo().volumeMounts and run mountpoint -q /mnt/data in the sandbox.

Expected: Dormice either mounts the requested volume or rejects the unsupported request. A nonexistent volume must not produce a successful unmounted sandbox.

Actual: Creation succeeds, getInfo().volumeMounts is empty, and /mnt/data is not mounted.

Impact: Applications can believe durable storage is attached while writes actually land on the sandbox's ordinary disk or fail because the path is absent. Data expected to survive sandbox deletion can be lost.

Relevant code and contract:

• packages/server/src/e2b/control.ts:61-72 uses a loose create schema that omits volumeMounts.
• packages/server/src/e2b/control.ts:342-352 calls executor.create with only an image.
• packages/server/src/e2b/control.ts:203-229 omits volume mounts from the sandbox info view.
• e2b 2.31.0 exposes volumeMounts on create and serializes it into the /sandboxes request.
• website/content/docs/e2b-differences.mdx:64-74 promises that unimplemented E2B operations are answered honestly rather than silently swallowed.

dor doctor output

Not applicable — this is an E2B create-request compatibility mismatch, not a host-readiness failure.

Environment

• Dormice commit: 4417ae14938273f5d937c476cf7cdc57e22e53a5
• SDK: e2b 2.31.0
• Executor: Docker + gVisor
• Verification: official SDK serialization trace and server create/info path trace