Repository navigation
feat(cli): expose --live-fork on forkd fork / from-image / run for spawn-time opt-in #209
Description
Activity
- added a commit that references this issue
on May 31, 2026 PR #211 closed half of this —
forkd fork --live-forknow exists and plumbsMemoryBackend::MemfdSharedthrough the local-boot path.What's still open: there's no CLI verb that spawns via the daemon. The two existing pieces don't compose:
forkd fork --live-forkboots Firecracker locally; the daemon doesn't track those processes.forkd snapshot --from-sandbox <id> --livehits the daemon'sPOST /v1/sandboxes/<id>/branch, which only knows about daemon-spawned sandboxes.
For a pure-CLI live-BRANCH workflow we'd need something like
forkd sandbox spawn --tag X --live-fork(or extendingforkd forkwith a--via-daemonflag) that POSTs to/v1/sandboxeswithlive_fork: true. Existing daemon-aware verbs (ls,kill,rmi) confirm that pattern fits the CLI.Also dropping the original "add to
from-image/run" parts of the scope:from-imagebuilds a snapshot TAG, butlive_forkis per-spawn, not per-tag — no place to apply it.runis a one-shot that kills the child after the exec, so a live-BRANCH target wouldn't exist long enough to use.
Re-titling mentally to "Add daemon-side
forkd sandbox spawn --live-forkCLI verb" for the remaining work.Scoping note for anyone picking this up (labeled good-first-issue):
forkd fork --live-forkalready landed (and #230 built--hugepageson top of it), so the remaining work is justfrom-imageandrun:- Add
#[arg(long)] live_fork: boolto theFromImageandRunvariants incrates/forkd-cli/src/main.rs(copy the doc comment + pattern from theForkvariant around line 206) - Thread it into
from_image_cmd/run_cmd→ setmemory_backend: MemoryBackend::MemfdShared { use_hugepages: false }when true (seefork_cmdaround line 2668 for the exact pattern) - Bonus points: also thread
--hugepageswithrequires = "live_fork"the same way feat(live-fork, memfd): Back Mem Snapshot with Hugepages #230 did forfork
No daemon or VMM changes needed — this is pure CLI plumbing with an existing template.
cargo run -p forkd-cli -- from-image --helpto verify the flag shows up.Happy to review quickly — recent first-PR turnaround here has been < 24h (#230, #236).
- Add
- added a commit that references this issue
on Aug 11, 2026
Gap
Phase 7.1 (REST
live_fork: trueonPOST /v1/sandboxes) and Phase 7.3 (Controller.spawn_sandboxes(live_fork=True)in Python/TS/MCP SDKs) shipped the spawn-time live-fork opt-in. The CLI did not get a matching flag.This means:
forkd snapshot --live(added in Phase 7.2) tells users "the source must have been created with `--live-fork`," but that flag doesn't exist.curlREST to setlive_fork: true.Scope
Add
--live-fork(bool flag) to:forkd fork(spawns N children from a registered snapshot)forkd from-image(Docker → rootfs → boot → register, then optionally spawn one)forkd run(one-shot spawn)For each, plumb the flag through to
POST /v1/sandboxesbody'slive_fork: true(the daemon already accepts it).Acceptance
forkd fork --tag X -n 1 --live-forkspawns a live-fork-capable child;forkd snapshot --from-sandbox <id> --livethen succeeds against itdocs/VENDORED-FIRECRACKER.md)forkd snapshot --livedoc comment can drop the "source must have been created with--live-fork" caveat into being literally true on the CLIWhy follow-up not blocking
mode: \"live\"itself works today via SDK or REST — this is purely CLI ergonomics. Filed honestly in the v0.4 CHANGELOG entry rather than papered over.