Repository navigation
feat(sdk): accept a sandbox policy in the Rust SDK's SandboxSpec #5410
Description
User Story
I write testkit tests that create a sandbox with a policy. I want the Rust SDK's SandboxSpec to accept a policy, so testkit uses the SDK's own create request instead of rebuilding it, and a policy works together with a GPU or service exposures.
Description
openshell_sdk::SandboxSpec has no policy field. To create a sandbox with a policy, testkit's SandboxBuilder::create (tests/testkit/testkit/src/context.rs, policy_create_request) builds the CreateSandboxRequest itself, mirroring the SDK's create_sandbox_request (crates/openshell-sdk/src/client.rs). It destructures SandboxSpec without .., so a new SDK field fails to compile there instead of being dropped, but the mapping is still duplicated. It doesn't map gpu or service_exposures, so create rejects a sandbox that combines them with a policy.
Evan raised this in the review of #5318.
Open question: the curated SandboxSpec avoids generated wire types and points callers to openshell_sdk::raw for the full proto surface. The field could take the proto SandboxPolicy, policy YAML, or a curated policy type.
Context
crates/openshell-sdk/src/types.rs:SandboxSpec.crates/openshell-sdk/src/client.rs:create_sandbox_request.tests/testkit/testkit/src/context.rs:SandboxBuilder::policy,policy_create_request, and the GPU and service-exposure check increate.
Definition of Done
-
SandboxSpec(or the SDK's create API) accepts a sandbox policy, with the type choice recorded here. -
create_sandbox_requestsetsspec.policyfrom it, with a unit test. - testkit passes the policy through the SDK and deletes
policy_create_requestand the GPU and service-exposure restriction.
Activity
elezar commentedon Nov 10, 2026
Related decision for this issue: whichever type
SandboxSpectakes also decides the shape of testkit's policy helpers. Todaypolicy::base,policy::allowandpolicy::to_yamlare free functions on the generatedproto::SandboxPolicy, whileEndpointis an extension trait. If the SDK takes the proto policy, an extension trait is the natural fit. If it takes YAML, the helpers can stay as they are withto_yamlas the hand-off. If it takes a curated type, they should become methods on it, with no testkit wrapper.Suggested Definition-of-Done item: reconsider the shape of
testkit::policyonce the type is decided. In scope:policy::base,policy::allow,policy::to_yaml, and the conformance suite's policy-taking helpers (allow,sandbox_with,create_sandbox,expect_rejected).Optional, once a second suite needs them:
SandboxBuilder::providers(&[...])and a create-and-wait method on the builder. Both are general, but onlycredential_gatinguses the pattern today.qipchip31 commentedon Nov 13, 2026
Thanks, @elezar. I’d like to take on #5410 and confirm the API before I start. Is it okay for testkit to serialize its protobuf policy with
to_yaml()and have the SDK parse it again, or should the first PR support typed input too?Would you prefer a separate
create_sandbox_with_policy()method? Even an optional field onSandboxSpecwould break callers that list every field in a struct literal.