@madarco/agentbox 0.13.0 → 0.15.0

package/dist/{prepared-state-MQHD3M5F-KE4DT3GX.js → prepared-state-MQHD3M5F-Q27AZU53.js}

@@ -6,7 +6,7 @@ import {
   readPreparedDockerState,
   resolveContextFiles,
   writePreparedDockerState
-} from "./chunk-SNTHHWKY.js";
+} from "./chunk-XKH7NTT7.js";
 export {
   DOCKERFILE_PATH,
   computeDockerContextFingerprint,
@@ -15,4 +15,4 @@ export {
   resolveContextFiles,
   writePreparedDockerState
 };
-//# sourceMappingURL=prepared-state-MQHD3M5F-KE4DT3GX.js.map
+//# sourceMappingURL=prepared-state-MQHD3M5F-Q27AZU53.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@madarco/agentbox",
-  "version": "0.13.0",
+  "version": "0.15.0",
   "description": "Launch Claude Code, Codex, and other coding agents in isolated sandboxes",
   "license": "MIT",
   "author": "Marco D'Alia",
@@ -46,6 +46,7 @@
     "@vercel/sandbox": "^2.0.1",
     "@xterm/headless": "^5.5.0",
     "commander": "^12.1.0",
+    "e2b": "^2.27.1",
     "execa": "^9.5.2",
     "supports-hyperlinks": "^3.1.0",
     "yaml": "^2.6.1"
@@ -61,13 +62,14 @@
     "@agentbox/config": "0.0.0",
     "@agentbox/core": "0.0.0",
     "@agentbox/ctl": "0.0.0",
-    "@agentbox/relay": "0.0.0",
     "@agentbox/sandbox-cloud": "0.0.0",
+    "@agentbox/relay": "0.0.0",
     "@agentbox/sandbox-core": "0.0.0",
+    "@agentbox/sandbox-docker": "0.0.0",
     "@agentbox/sandbox-daytona": "0.0.0",
     "@agentbox/sandbox-hetzner": "0.0.0",
-    "@agentbox/sandbox-vercel": "0.0.0",
-    "@agentbox/sandbox-docker": "0.0.0"
+    "@agentbox/sandbox-e2b": "0.0.0",
+    "@agentbox/sandbox-vercel": "0.0.0"
   },
   "scripts": {
     "build": "tsup",

package/runtime/docker/Dockerfile.box

@@ -268,16 +268,20 @@ RUN npm install -g opencode-ai
 #     the noble transition. If the base image moves back to jammy these will
 #     need the un-suffixed names.
 #
-#  2. Get an actual Chromium binary. `agent-browser install` would normally
-#     download Chrome for Testing, but Chrome for Testing has no Linux ARM64
-#     build (Apple Silicon hosts run linux/arm64 containers) and Noble's
-#     `chromium-browser` apt package is a snap stub that won't run inside a
-#     container. The reliable cross-arch source is Playwright's bundled
-#     Chromium, so we install playwright globally just for its
-#     `playwright install chromium` downloader, then point agent-browser at
-#     the resulting binary via AGENT_BROWSER_EXECUTABLE_PATH. agent-browser
-#     honours that env var (priority: CLI flag > env > config file >
-#     built-in default; see agent-browser's README).
+#  2. Provide a Chromium *lazily*, shared with the project's Playwright. We do
+#     NOT bake a Chromium download into the image: Playwright pins an exact
+#     build per playwright version, so a baked browser goes stale the instant a
+#     project pins a different Playwright — its `playwright install` fetches a
+#     different build and anything waiting on the baked path hangs. Instead,
+#     `AGENT_BROWSER_EXECUTABLE_PATH` points at the `chromium-resolver` script
+#     (installed as /usr/local/bin/chromium below), which reuses the project's
+#     Playwright Chromium when present and otherwise installs one on first use
+#     with the project's pinned Playwright (matching build), falling back to the
+#     box's global Playwright. agent-browser honours that env var (priority: CLI
+#     flag > env > config file > built-in default; see agent-browser's README).
+#     Chrome-for-Testing has no linux/arm64 build and Noble's chromium apt
+#     package is a snap stub, so Playwright's downloader stays the only reliable
+#     cross-arch source — we just invoke it lazily instead of at build time.
 #
 # Runtime state (sessions, auth cookies under ~/.agent-browser/) lives in the
 # container's writable layer, preserved across pause/unpause/stop/start and
@@ -290,6 +294,8 @@ RUN apt-get update \
         fonts-liberation xdg-utils \
     && rm -rf /var/lib/apt/lists/*
 
+# agent-browser + a global playwright (the latter is only the lazy fallback
+# Chromium downloader for projects that don't pin their own Playwright).
 RUN npm install -g agent-browser playwright
 
 # Portless CLI (https://portless.sh). Only the client — the box never runs the
@@ -299,22 +305,11 @@ RUN npm install -g agent-browser playwright
 # Requires Node 24+ — hence the setup_24.x bump above.
 RUN npm install -g portless
 
-# Download Chromium as `vscode` so the ms-playwright cache lands in vscode's
-# home (the user agent-browser runs as). The downloaded binary lives at
-# `chromium-XXXX/chrome-linux*/chrome`, where XXXX is a Playwright-internal
-# revision number that changes between releases — and the inner dir is
-# `chrome-linux` for old releases and `chrome-linux64` (or `chrome-linux/arm64`)
-# for current Chrome-for-Testing builds. Glob both. We resolve once and write
-# a stable symlink so AGENT_BROWSER_EXECUTABLE_PATH can point at something
-# predictable.
-USER vscode
-RUN playwright install chromium \
-    && CHROME_BIN="$(ls /home/vscode/.cache/ms-playwright/chromium-*/chrome-linux*/chrome 2>/dev/null | sort | tail -1)" \
-    && test -n "$CHROME_BIN" \
-    && ln -sf "$CHROME_BIN" /tmp/chromium-link \
-    && test -x "$(readlink /tmp/chromium-link)"
-USER root
-RUN mv /tmp/chromium-link /usr/local/bin/chromium
+# /usr/local/bin/chromium is a resolver (not a baked binary): on first launch it
+# reuses the project's Playwright Chromium or installs one on demand, then execs
+# it. See the script header and the rationale in the browser-support note above.
+COPY packages/sandbox-docker/scripts/chromium-resolver /usr/local/bin/chromium
+RUN chmod +x /usr/local/bin/chromium
 
 ENV AGENT_BROWSER_EXECUTABLE_PATH=/usr/local/bin/chromium
 

package/runtime/docker/apps/cli/share/agentbox-setup/SKILL.md

@@ -48,7 +48,42 @@ Look at `/workspace`:
 - No cycles in `needs:`.
 - **Always generate a dependency-install task** and make it the root of the `needs:` graph (every service that needs deps gets `needs: [install, …]`). Future boxes start from a snapshot of the final filesystem so they won't need this, but updates or moving to a cloud provider might need to rebuild the container from scratch. The filesystem can be then later captured by `agentbox-ctl checkpoint --set-default`. The task must be **idempotent and self-healing**: `agentbox-ctl` re-runs pending tasks on every box stop/start (the daemon dies with the container and is relaunched), so a plain `rm -rf node_modules && install` would wipe + reinstall on every start. Guard the rebuild with a marker file *inside* `node_modules` (the `.agentbox-installed` convention AgentBox uses internally): rebuild only when the marker is absent (fresh box), and be a fast no-op once it exists. Detect the package manager from the lockfile — never hardcode `pnpm`. See the worked example below.
 - **Add a comment to the beginning** of the file to explain what you did and what issues you encountered, so that future run might use this information in case the project evolves and you need to update the agentbox.yaml file.
--
+
+### Stateful services: data persistence & re-seeding (read this for databases)
+
+**A checkpoint does NOT capture docker-in-docker data.** `agentbox checkpoint` is a `docker commit` of the box's writable filesystem (the system + `/workspace`). The in-box `dockerd` keeps its storage in a *separate* per-box volume (`/var/lib/docker`), which is **not** part of that image — it's fresh on every new box and wiped on `agentbox destroy`. So a database or cache you run as a **docker container** (e.g. `docker run … postgres`) starts **empty on every new box** created from a checkpoint (every `agentbox claude` / `agentbox create`), even though `/workspace` and any marker files you wrote were restored. (A DB run as a **native process** with its data dir on the box filesystem — e.g. `postgres -D /var/lib/postgresql/data` — *is* captured by the checkpoint, since it lives in the writable layer.)
+
+**Consequence for migrate/seed tasks of a containerized DB: do not gate them on a filesystem marker.** A marker like `node_modules/.agentbox-installed` is correct for deps (they live in `/workspace`, which the checkpoint captures), but **wrong** for DB data living in a docker volume: the marker is restored from the checkpoint while the DB is empty, so a marker-guarded seed wrongly skips and the app boots against an empty database. Instead, **gate on the actual data** — connect to the DB and check whether a sentinel table/row exists, and seed only when it's missing:
+
+```yaml
+  seed:
+    # Re-seed when the DB is empty. The postgres data lives in the in-box
+    # docker volume, which is NOT captured by `agentbox checkpoint` — so a box
+    # started from a checkpoint has the workspace warm but an empty DB. We can't
+    # use a filesystem marker here (it would be restored while the DB is blank);
+    # instead probe the DB and seed only if the data is absent. Fast no-op once
+    # the data is present.
+    command: |
+      set -e
+      export PGPASSWORD=postgres
+      # Probe for existing data. If the table is missing the query errors,
+      # stderr is suppressed, stdout is empty, the grep fails — so we seed.
+      if psql -h 127.0.0.1 -p 5432 -U postgres -d app -tAc \
+          "SELECT EXISTS (SELECT 1 FROM users LIMIT 1)" 2>/dev/null | grep -q t; then
+        echo "data present — skip seed"
+        exit 0
+      fi
+      pnpm db:seed
+    needs: [install, migrate]
+```
+
+**Lifecycle nuance (this is why the data check, not a marker, is right):**
+
+- **Box stop → start** (`agentbox stop`/`start`): the supervisor daemon dies with the container and is relaunched, so it **re-runs all tasks** from `pending`. The per-box docker volume *does* survive stop/start, so the DB still has data — the data check makes the seed a fast no-op.
+- **New box from a checkpoint** (`agentbox claude`/`create`): tasks run and the DB volume is empty → the check fails → the seed runs. Correct.
+- **Resume after pause** (`agentbox pause`/`unpause`): the daemon is frozen and thawed, **not** restarted, so tasks do **not** re-run at all — nothing to seed, the running DB is untouched.
+
+(Migrations are usually safe to re-run as-is: migration tools track applied migrations in their own table, which on a fresh box is empty, so they simply re-apply. Only the *data* seed needs the existence check.) Install the DB client the seed/migrate tasks need (e.g. `postgresql-client`) in the `install` task — don't `docker exec` the DB container for these checks (nested `docker exec` fails inside a box with a `setns` error); reach it over TCP with the client tools instead.
 
 ## 3. Wire readiness probes (services only)
 
@@ -157,6 +192,36 @@ services:
       factor: 2
 ```
 
+## 6b. Bringing extra host files/folders into the box
+
+Two ways to copy host files in (both COPY — never a live mount, so the box can't
+write back to the host):
+
+- **`carry:` block** (declarative, in `agentbox.yaml`) — for files/dirs every box
+  should get at create time. Each entry is `{ src, dest }` with optional `mode`,
+  `user`, `optional`, and `exclude:` (a list of tar globs / bare dir names to drop
+  when copying a directory). Heavy regenerable dirs (`.git`, `node_modules`, `bin`,
+  `obj`, `packages`, `dist`, `.next`, `target`) are dropped by default; `exclude:`
+  is additive. Each carry entry is capped at `box.cpMaxBytes` (default 100 MiB
+  after excludes) — the same limit `agentbox cp` enforces.
+- **`agentbox-ctl cp fromHost <hostPath> <boxPath>`** (ad-hoc, from inside the box)
+  — for a one-off copy. Prompts the user on the host to approve.
+
+**The per-copy size limit (important for large/legacy folders).** A single copy is
+blocked above `box.cpMaxBytes` (default **100 MB**) *after* default excludes, so it
+fails loud instead of silently hanging. When blocked you get a `du`-style tree of
+the biggest remaining folders/subfolders. To get under the limit, EITHER:
+
+- **drop what the box can regenerate** (the default excludes already remove
+  `node_modules`/`.git`/build output; add more with `--exclude=<glob-or-name>`), OR
+- **copy the heavy folders one at a time** so each copy is under the limit, OR
+- pass `--yes` to copy the whole thing anyway (only when you really need it all).
+
+Example: a 2.4 GB legacy folder is mostly `packages/` (NuGet) + `.git`; those are
+excluded by default, and what's left can be split:
+`agentbox-ctl cp fromHost ../legacy/src /workspace/legacy/src` then
+`... cp fromHost ../legacy/Database /workspace/legacy/Database`.
+
 ## 7. Validate before handing off
 
 - check with `agentbox-ctl reload` and then `agentbox-ctl status` that everything is running as expected.
@@ -184,6 +249,7 @@ Tell the user (verbatim):
 ## 9. Checkpoint the warm state - DON't SKIP THIS STEP
 
 Checkpoint (snapshot) this box writable layer: once the box is warmed up (deps installed, services ready), checkpoint it with `agentbox-ctl checkpoint --name setup --replace --set-default` so future boxes start ready.
+Remember the checkpoint captures the writable layer (`/workspace` + system), **not** docker-in-docker volumes — so a containerized DB's data does not carry into new boxes. That's expected; the data-existence-gated seed task from section 2 re-seeds those automatically. (If you need the data itself to persist into new boxes, run the DB as a native process with its data dir on the box filesystem, or bind a `/workspace` path as the container's data volume so it lands in the checkpoint.)
 Run this command exactly once. The `--name setup --replace` makes it idempotent — if it ever needs to run again it overwrites the existing `setup` checkpoint instead of stacking duplicates.
 On all providers except Vercel, this doesn't need to be confirmed by the user. It will pause the container for several seconds so warn the user about it and write Done when it's done.
 On Vercel: this actually STOPS the sandbox, so warn the user about it. Also the system will ask confirmation.