Repository navigation
feat(sandbox): support gated host mounts through driver_config #1760
Description
Activity
I need this capability right now. My use case is agents running on top of a shared GitOps-style substrate, that is used as the system of record. Copying in and out of the container is messy. The git repo itself is contained and there is little or no risk as any agent-initiated changes can be rolled back.
Reacted by Space MannThis issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
- addedstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
on Jun 23, 2026 @randybias we have landed initial support for specifying mounts in k8s, Docker, and Podman. See #1744 and #1785.
In terms of this issue, we don't yet have a mechansims to limit the mounts, but that could be added in the context of #1927.
- removedstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
on Jun 25, 2026 Awesome. Will take it for a test drive soon. 🙏
On the rootless Podman/Docker driver, a read_write host mount writes files owned by a subuid, not the user who started the sandbox.
Concretely (rootless Podman 5.8.4, kernel 6.17): the agent runs as uid 1000 in the sandbox, writes to a bind-mounted host dir, and on the host the file ends up owned by 100999:100999. So read_write: true mounts work, but you can't cleanly edit or commit those files as yourself afterward — which defeats the main use case of live-editing your own repo in place.
Could host_mounts include an opt-in idmap flag? When set, id-map the mount so the sandbox uid maps to the host owner, and writes land owned by the host user (like Podman's -v src:dst:idmap). Default off, so nothing changes unless you ask for it.
The capability already exists in-tree — the Kubernetes driver does user namespaces + ID-mapped mounts (enable_user_namespaces). This would bring the same idmap to the podman/docker bind path. Rootless idmap bind mounts work on recent kernels (verified: podman run -v dir:/mnt:idmap … gives correct 1000:1000 ownership, no EPERM on 6.17).
Without it, read_write host mounts are really only usable rootful (where container uid 1000 == host uid 1000); rootless users get subuid-owned files.
I agree that would be useful. My initial tests with Docker were positive, but this would definitely make it easier to use.
Setting the sandbox's user namespace to keep-id in the podman driver's create spec fixes it — the agent's writes to read_write host mounts land owned by the host user (1000) instead of a subuid. Verified on rootless Podman 5.8.4.
// crates/openshell-driver-podman/src/container.rs — ContainerSpec create spec
userns: std::env::var("OPENSHELL_SANDBOX_USERNS") // e.g. "keep-id"
.ok().filter(|s| !s.is_empty())
.map(|nsmode| UserNS { nsmode }),would this also include FUSE ? we have been struggling to get a FUSE-based cloud filesystem (like s3fs) to run inside openshell. i think the architecture prevents a fuse daemon to run and mount filesystems before the rest of the openshell kicks in.
a lot of us use agents with fuse based filesystems to access data.
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
- addedstate:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.
on Aug 28, 2026
Problem Statement
OpenShell sandboxes currently have no first-class way to request live host
filesystem mounts through the driver-specific sandbox configuration path. The
existing
sandbox uploadandsandbox downloadflows are copy-based, which issafe and portable but does not cover long-running workflows that need a live,
read-only view of host data such as repositories, local reference data,
diagnostic artifacts, or operator-provided shared directories.
Historically, host mounts have been rejected or deferred because they are
security-sensitive and driver-specific. That concern still applies. The new
SandboxTemplate.driver_configpassthrough proposal gives us a better boundary:the public API can stay generic, the gateway can remain driver-agnostic, and
each compute driver can own validation and rendering for its own runtime.
The missing design is a common, safe-by-default
host_mountsschema underdriver_config, with driver-level admin gates, allowlisted host prefixes, andread-only behavior by default.
Proposed Design
Add a driver-owned
host_mountsschema under the active driver'scontainers.agentconfig:{ "kubernetes": { "containers": { "agent": { "host_mounts": [{ "name": "shared-data", "host_path": "/var/lib/openshell/shared", "mount_path": "/mnt/shared", "type": "Directory" }] } } }, "docker": { "containers": { "agent": { "host_mounts": [{ "name": "shared-data", "host_path": "/var/lib/openshell/shared", "mount_path": "/mnt/shared" }] } } }, "podman": { "containers": { "agent": { "host_mounts": [{ "name": "shared-data", "host_path": "/var/lib/openshell/shared", "mount_path": "/mnt/shared" }] } } } }Field semantics:
name: required logical name, valid for the active driver and unique withinthe request.
host_path: required absolute path on the compute host.mount_path: required absolute path inside the agent workload.read_write: optional, defaults tofalse. Omit it for read-only mounts.read_write: trueshould be rejected in the first implementation unless theactive driver has an explicit read-write admin gate.
type: optional and driver-specific. Kubernetes maps this tohostPath.type; Docker and Podman should reject non-empty values initiallyunless they implement equivalent validation.
Add driver config gates:
First-pass behavior:
host_mountsunless the active driver hasallow_host_path_mounts = true.read_write: trueunless a future explicitallow_read_write_host_path_mountsgate is added.ValidateSandboxCreateand again beforerendering during
CreateSandbox.Driver rendering:
hostPathvolumes plusvolumeMountson the agent container. Set
readOnly: !read_write.HostConfig.binds, following theexisting internal bind style for read-only mounts.
mountsarray as bindmounts with
["ro", "rbind"], pluszwhen SELinux is enabled.driver_config.vm.containers.agent.host_mountsfor now with aclear unsupported message. VM support needs a separate transport decision
such as virtiofs, 9p, or an extra block image, plus guest init integration.
Validation should reject:
host_mounts;host_path/mount_path;/sandbox,/var/run/secrets/openshell,/run/netns, TLS mount directories, andsupervisor mount directories;
typevalues;read_write: trueuntil writable mounts have a separate security design.Documentation should cover Docker Desktop and Podman machine path-resolution
semantics: paths are resolved by the daemon/VM host, not necessarily the
gateway process filesystem.
Alternatives Considered
mounts are driver-specific and should not force a lowest-common-denominator
API.
records, not filesystem access grants.
review and validation too broad.
sandbox upload/sandbox download: safe and portable, but copy-based andnot a live filesystem view.
guest-init design. This proposal should reject VM host mounts until that work
is intentionally designed.
Agent Investigation
Local codebase findings:
SandboxTemplate.driver_configexists on the public API and is forwarded asthe selected driver block to
DriverSandboxTemplate.driver_config.crates/openshell-server/src/compute/mod.rsselects the active driver blockand keeps the gateway out of nested schema validation.
crates/openshell-driver-kubernetes/src/driver.rsalready decodesdriver-local config for pod scheduling and agent resources, and already
renders managed volumes/mounts for TLS, ServiceAccount bootstrap, supervisor
sideloading, and workspace persistence.
crates/openshell-driver-docker/src/lib.rsalready builds driver-owned bindmounts for the supervisor binary, TLS files, and sandbox token through
HostConfig.binds.crates/openshell-driver-podman/src/container.rsalready renders bind mountsfor TLS/token files and has SELinux-aware mount options.
crates/openshell-driver-vm/src/driver.rscurrently rejectsplatform_config; VM host sharing needs a transport and guest mount designbefore support can be claimed.
Related issues and PRs:
driver_config.gateway bootstrap rather than sandbox workload mounts.
Definition of Done
Podman driver config.
duplicate names/targets, reserved targets, unsupported types, read-write
rejection, and VM unsupported behavior.