Repository navigation
OpenShellSpawner: Cross-platform skills_image extraction via crane #106
Description
Context
_load_skills() in OpenShellSpawner currently extracts skills from OCI images using the Podman Python SDK, which requires a Podman socket. This works when:
- OpenShell gateway uses the Podman driver (runner has Podman socket mounted) ✅
- Runner runs on a host with Podman ✅
It fails when:
- OpenShell gateway uses the K8s driver (runner is a K8s pod with no Podman socket) ❌
- Any environment without a container runtime accessible to the runner ❌
The current code raises RuntimeError("neither Podman SDK nor podman CLI available") in these cases.
Solution
Use crane (google/go-containerregistry) as the primary skills image extraction method:
- Single static Go binary (~15MB), no daemon required
- Pulls from any OCI registry using standard auth (registry credentials, service account tokens)
- Exports image content as a tar stream:
crane export <image> - - Works in any environment — K8s pods, containers, bare metal
Changes
- Runner Containerfile: Add
cranebinary (download from GitHub releases during build) _extract_skills_image(): Usecrane export <image> - | tar xf - -C /tmp/skills/as primary path- Fallback chain:
crane→ Podman SDK → podman CLI → RuntimeError - Tests: Cover crane path, Podman SDK fallback, and no-runtime error
Flow
Runner Sandbox
| |
|-- crane export <image> ----------> tar bytes in memory
| |
|-- exec_stream(tar xf stdin) -----> /app/skills/ populated
The sandbox-side upload (exec_stream with tar) is unchanged — only the extraction method changes.
Verification
- Unit tests: mock
subprocess.runfor crane, verify tar output piped to exec_stream - E2E on EC2: OpenShell + Podman driver with skills_image workflow
- E2E on Kind: OpenShell + K8s driver (runner as K8s pod) with skills_image workflow
Activity
beesarmy commentedon Jul 11, 2026
Triage
Summary: Replace Podman-dependent skills image extraction with
crane(static Go binary) for cross-platform support — enables K8s driver deployments where no Podman socket is available.Affected components:
src/cloud_agents/spawner/openshell_spawner.py—_load_skills()(line 575),_extract_skills_image()(line 601)cranebinaryRelated issues/PRs:
Suggested labels:
enhancement,area/spawnerPlan review:
_extract_skills_image()uses Podman SDK/CLI, confirmed at line 601. Fails on K8s driver deployments.craneis a well-known tool for daemon-less OCI image operations — correct choice for this use caseexec_streamtar) unchanged — clean separation of extraction vs injectioncrane→ Podman SDK → podman CLI → error) is defensivecranebinary in runner image adds ~15MB. Consider whether it should be optional (only included in OpenShell-aware runner builds) or always bundled.crane— plan says "standard auth" but doesn't specify how credentials reachcranein a K8s pod.cranereads~/.docker/config.jsonorDOCKER_CONFIGby default. If the runner pod has a pull secret mounted,craneneeds to be pointed at it.Non-blocking⚠️ only. Plan approved.
🤖 Triaged by beesarmy via Claude Code
RSPEED-0000: Skills image via Podman driver_config + fragility analys…
Fix command injection via skills_paths across all three spawners (#203)
Redesign skills delivery: bake into image, scope per-step via Landlock (
jameswnl commentedon Aug 28, 2026
Closing as superseded, not implemented as originally planned. #202 (closed 2026-08-28) found the whole crane/Podman-extraction + tar-upload approach broken for two stacked reasons (this issue, plus a separate permissions bug in #201) and redesigned the mechanism entirely: skills now ship baked into the sandbox image at build time, scoped per-run via allowed_skills/Landlock instead of extracted at runtime.
_load_skills()/_extract_skills_image()no longer exist in openshell_spawner.py -- the Podman-socket dependency this issue was about is gone along with the code that needed it.