Last hub asset still on a pre-#242 (un-portable) pack. Unlike the other 8, coding-agent-fork is not a from-image bake — it's a runtime-populated branch snapshot:
recipes/coding-agent-fork/setup-source.sh runs inside a booted coding-agent sandbox and populates /tmp/workspace (the buggy mathy package, a 50 MiB vendored.bin, __pycache__ from a failing test run). The demo then forkd branches that running sandbox. The whole point is that /tmp/workspace state is captured at the branch point.
Why it can't be baked like the others:
rootfs-init/forkd-init.sh mounts tmpfs on /tmp (size 256m) — deliberately, so per-sandbox scratch survives BRANCH via guest RAM (memory.bin). So injecting /tmp/workspace into the rootfs at build time is masked at boot; the state must be populated at runtime and captured in memory.bin.- Faithful reproduction therefore needs the daemon flow: spawn from
coding-agent (now a portable hub pull) → exec setup-source.sh via the guest agent → forkd snapshot --from-sandbox.
Blocker for doing it in the throwaway-container harness used for the other 8: the guest-agent exec networking returns No route to host inside the privileged container (per-child netns ↔ host-bridge NAT doesn't complete there). So the asset can't be built or verified in that harness.
To do (on a host where the daemon guest-agent flow works)
Priority: low — it's a demo asset, not a runtime base. The 8 real bases (python-numpy, nodejs, langgraph-react, coding-agent, postgres-fixture, jupyter-kernel, e2b-codeinterpreter, playwright-browser) are all portable as of the #242 follow-up batches (#248, #249, #251, and the playwright update).
Last hub asset still on a pre-#242 (un-portable) pack. Unlike the other 8,
coding-agent-forkis not a from-image bake — it's a runtime-populated branch snapshot:recipes/coding-agent-fork/setup-source.shruns inside a booted coding-agent sandbox and populates/tmp/workspace(the buggymathypackage, a 50 MiBvendored.bin,__pycache__from a failing test run). The demo thenforkd branches that running sandbox. The whole point is that/tmp/workspacestate is captured at the branch point.Why it can't be baked like the others:
rootfs-init/forkd-init.shmounts tmpfs on/tmp(size 256m) — deliberately, so per-sandbox scratch survives BRANCH via guest RAM (memory.bin). So injecting/tmp/workspaceinto the rootfs at build time is masked at boot; the state must be populated at runtime and captured inmemory.bin.coding-agent(now a portable hub pull) → execsetup-source.shvia the guest agent →forkd snapshot --from-sandbox.Blocker for doing it in the throwaway-container harness used for the other 8: the guest-agent exec networking returns
No route to hostinside the privileged container (per-child netns ↔ host-bridge NAT doesn't complete there). So the asset can't be built or verified in that harness.To do (on a host where the daemon guest-agent flow works)
forkd pull deeplethe/coding-agent(portable base)forkd-controller, spawn a sandbox fromcoding-agentrecipes/coding-agent-fork/setup-source.shin the guest (populates/tmp/workspace)forkd snapshot --from-sandbox <id> --tag coding-agent-forkhub-coding-agent-fork-v1, update registry.jsonforkd pull deeplethe/coding-agent-fork→ fork → confirm/tmp/workspace+ byte-identicalvendored.binacross children (the demo's invariant)Priority: low — it's a demo asset, not a runtime base. The 8 real bases (python-numpy, nodejs, langgraph-react, coding-agent, postgres-fixture, jupyter-kernel, e2b-codeinterpreter, playwright-browser) are all portable as of the #242 follow-up batches (#248, #249, #251, and the playwright update).