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
bug: openshell sandbox create --from OOM-killed on large images #601
Investigated using the create-spike skill backed by principal-engineer-reviewer. Skills loaded: debug-openshell-cluster, openshell-cli, create-spike.
Traced sandbox create --from through run.rs → build.rs → push.rs
Confirmed three discrete full-image heap allocations in push_local_images() at push.rs:54–55
Verified bollard::upload_to_container accepts body_try_stream() — no API constraint blocks a streaming fix
Confirmed the tar crate size-in-header constraint requires a seekable (disk) intermediate; fully in-memory zero-copy is not feasible
Found tempfile is already a dev-dep; needs promotion to prod dep
No test coverage exists for push.rs
Description
Running openshell sandbox create --from <dockerfile-dir> on a large sandbox image (~3.7 GB) causes the openshell process to be killed by the Linux OOM killer. The image export pipeline in crates/openshell-bootstrap/src/push.rs buffers the entire Docker image tar three times in memory before importing it into the gateway, producing ~11 GB peak allocation.
The three allocations in push_local_images():
collect_export (push.rs:97–107) — streams docker.export_images() into a Vec<u8> (~3.7 GB)
wrap_in_tar (push.rs:114–131) — copies that Vec<u8> into a second tar-wrapped Vec<u8> (~3.7 GB); both are live simultaneously, peak ~7.4 GB
upload_archive (push.rs:135–151) — calls Bytes::copy_from_slice(archive) creating a third copy (~3.7 GB); all three overlap in scope, peak ~11 GB
Expected: the export → tar wrap → upload pipeline streams data in O(chunk) memory.
Reproduction Steps
Build a large sandbox image (≥ 3 GB uncompressed):
This issue appears to have been opened without an agent investigation.
OpenShell is an agent-first project - please point your coding agent at the repo and have it diagnose this before we triage. Your agent can load skills like debug-openshell-cluster, debug-inference, openshell-cli, and generate-sandbox-policy.
I suggest refactoring this into a streaming pipeline—likely using tempfile to handle the tar header size requirement while keeping RAM usage constant. This would allow the process to handle multi-GB images with minimal memory footprint.
Activity
github-actions commentedon Mar 25, 2026
This issue appears to have been opened without an agent investigation.
OpenShell is an agent-first project - please point your coding agent at the repo and have it diagnose this before we triage. Your agent can load skills like
debug-openshell-cluster,debug-inference,openshell-cli, andgenerate-sandbox-policy.See CONTRIBUTING.md for the full workflow.
minhdqdev commentedon Mar 25, 2026
I suggest refactoring this into a streaming pipeline—likely using tempfile to handle the tar header size requirement while keeping RAM usage constant. This would allow the process to handle multi-GB images with minimal memory footprint.
I can put a PR to fix it.
openshell sandbox create --fromOOM-killed on large images #602