You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Mount shared folder from host into VM based sandbox #2585
The VM driver currently has no way to share a host directory into the sandbox
The Docker and Podman drivers already solve this via --driver-config-json's mounts field ({"docker":{"mounts":[{"type":"bind","source":...,"target":...}]}}), documented in the
sandbox-compute-drivers reference.
There's no VM-driver equivalent, so a project that needs a live, bidirectional view of a host working directory (e.g. so a coding agent inside the
sandbox can edit files and have the host see the changes immediately, and vice versa) cannot use the VM driver at all today.
Proposed Design
Introduce a VM driver's --driver-config-json schema with a mounts field:
The field names intentionally match the concept the operator cares about (a host path made available at a guest path).
Internally:
The VM driver already depends on libkrun, which supports host-directory sharing as a first-class feature via krun_add_virtiofs(ctx_id, tag, host_path). It defines a tag plus a host path. There's no host-specified mount point in that primitive; virtiofs only exports a directory under a tag. Therefore on the guest side it has to be mounted via mount -t virtiofs <tag> <path>.
The guest-side mount -t virtiofs <tag> <target> would need to run during the VM driver's own boot/supervisor sequence, before handing off to the sandboxed process
mounts are a create-time-only option, consistent with how Docker
driver mounts are also specified at sandbox create rather than added to a running sandbox.
Alternatives Considered
One-shot --upload at sandbox-create time. Already supported today, driver-agnostic. Rejected as a full substitute because it's a point-in-time snapshot, not a live bidirectional sync. Host edits during the session aren't reflected in the sandbox and vice versa.
Agent Investigation
No response
Checklist
I've reviewed existing issues and the architecture docs
This is a design proposal, not a "please build this" request
Activity
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
benoitf commentedon Sep 18, 2026
I'll work on it for macOS/libkrun
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1
chore(vm): bump libkrun to v1.19.4 and libkrunfw to v5.6.1 (NVIDIA#3451)
SidShaytay commentedon Oct 1, 2026
Could you confirm whether #2585 will cover Linux/KVM hosts? Any Fedora Silverblue specific constraints we should plan for?