Skip to content

feat(framework): run the --serve verification in a Docker sandbox (#229)#277

Merged
suleimansh merged 1 commit into
mainfrom
feat/docker-serve-sandbox
Jul 5, 2026
Merged

feat(framework): run the --serve verification in a Docker sandbox (#229)#277
suleimansh merged 1 commit into
mainfrom
feat/docker-serve-sandbox

Conversation

@suleimansh

Copy link
Copy Markdown
Member

Closes #229 (first slice).

Today framework --serve ... boots the generated app on the host to verify it runs. This adds --sandbox docker so that verification happens inside a throwaway container instead: the source is copied in, deps install and the dev server run in the container, and the health check hits a mapped port. Agent-authored code never installs or runs on the host to be checked. --sandbox local (default) is unchanged (adopts the host cwd in place).

Scope, per the issue's suggested first slice: only the serve verification is sandboxed. The build itself (Claude Code) still runs on the host, so the container is re-seeded with the latest host source before each check (each pass changes it). Sandboxing the build is the larger next step.

How it fits the existing seam:

  • The Runner interface + DockerRunner already exist (ai-autopilot: sandboxed runner adapters (Docker / WebContainer / Flue) #109/feat(ai-autopilot): WebContainerRunner (in-browser sandboxed runner) #223); nothing in ai-autopilot changed. run.ts just provisions Local vs Docker behind the same serveCheck.
  • New snapshotWorkspace(cwd) reads the host workspace into a FileTree (skips node_modules/.git/dist/etc., binaries, oversized files) to seed the container — the Docker analog of LocalRunner.adopt.
  • runFramework gains sandbox?: 'local'|'docker' and an injectable runner? (advanced/testing seam).
  • Requires a reachable Docker daemon: a run that asks for the sandbox without one fails fast with a clear message. --sandbox docker without --serve is a no-op note.

Verified end to end against a real daemon (Docker 29.6): a tiny server boots and serves inside the container and the gate passes (productionGrade). The docker e2e test is guarded by dockerAvailable() so CI without a daemon skips it. 144 framework tests green.

One naming call for you (like LoopEngine/DomainPreset before): I named the flag --sandbox (forward-looking — it will also govern the build once that is sandboxed), even though in this slice it only wraps the serve check. Happy to rename to something serve-scoped if you'd rather.

@suleimansh suleimansh added enhancement New feature or request priority: medium Worth doing, not urgent labels Jul 5, 2026
@suleimansh suleimansh self-assigned this Jul 5, 2026
@suleimansh suleimansh merged commit 9f62be7 into main Jul 5, 2026
2 checks passed
@suleimansh suleimansh deleted the feat/docker-serve-sandbox branch July 5, 2026 19:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request priority: medium Worth doing, not urgent

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Build inside a sandboxed Runner (Docker) instead of the host

1 participant