fix(bot): bake Chrome into the sandbox image at build time

[ascorbic]

What does this PR do?

Bakes Chrome into the emdash-bot sandbox image at build time so the
browser-driven repro skills (repro-admin, repro-public) can actually launch
a browser.

At runtime the sandbox egress allowlist only passes GitHub/npm hosts, so
agent-browser install — which fetches Chrome for Testing from Google hosts —
can never succeed inside a running container. During eval run 8 this blocked
browser verification on two cases (#1272, #1124): the agent got as far as
needing the UI and died on "Chrome install failed" SSL errors from the
intercepting proxy.

The fix follows the image's existing multi-stage pattern (all TLS work happens
in the node-source stage, which has a working CA bundle): run
agent-browser install there and COPY the resulting
/root/.agent-browser cache into the final image. The daemon auto-detects the
baked copy, so the repro skills need no changes and no runtime download is
ever attempted. The Chrome version is pinned by the image build (agent-browser
0.30.1, Chrome for Testing stable at build time — currently 151.0.7922.77).

Verified locally in the built container (linux/amd64 under Rosetta):
agent-browser doctor reports 8 pass / 0 warn / 0 fail including its live
headless-launch test ("Headless launch + about:blank in 3.84s"), and an
open → get text → close round-trip renders and reads a page against the
baked Chrome with no network install attempt.

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (n/a — Dockerfile-only change; verified by a live browser-launch test in the built container, which CI cannot run)
• User-visible strings in the admin UI are wrapped for translation (n/a — no UI change)
• I have added a changeset (n/a — infra worker image, not a published package)
• New features link to an approved Discussion (n/a — not a feature)

AI-generated code disclosure

• This PR includes AI-generated code — model/tool: Claude Fable 5 (Claude Code)

Screenshots / test output

agent-browser doctor inside the built image:

Launch test
  pass  Headless launch + about:blank in 3.84s

Summary: 8 pass, 0 warn, 0 fail

open / get text round-trip:

$ agent-browser open "data:text/html,<h1 id=t>baked-chrome-works</h1>"
✓
$ agent-browser get text "#t"
baked-chrome-works
$ agent-browser close
✓ Browser closed

---

Try this PR

Open a fresh playground →

A full working EmDash site, deployed from this branch. Each visit gets its own session-scoped sandbox: no login needed and no shared state. Try the admin, edit content, hit the public site.

_{Tracks bot/sandbox-baked-chrome. Updated automatically when the playground redeploys.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: f15551a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@emdash-cms/admin

npm i https://pkg.pr.new/@emdash-cms/admin@2416

@emdash-cms/auth

npm i https://pkg.pr.new/@emdash-cms/auth@2416

@emdash-cms/auth-atproto

npm i https://pkg.pr.new/@emdash-cms/auth-atproto@2416

@emdash-cms/blocks

npm i https://pkg.pr.new/@emdash-cms/blocks@2416

@emdash-cms/cloudflare

npm i https://pkg.pr.new/@emdash-cms/cloudflare@2416

@emdash-cms/contentful-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/contentful-to-portable-text@2416

emdash

npm i https://pkg.pr.new/emdash@2416

create-emdash

npm i https://pkg.pr.new/create-emdash@2416

@emdash-cms/gutenberg-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/gutenberg-to-portable-text@2416

@emdash-cms/plugin-cli

npm i https://pkg.pr.new/@emdash-cms/plugin-cli@2416

@emdash-cms/plugin-types

npm i https://pkg.pr.new/@emdash-cms/plugin-types@2416

@emdash-cms/registry-client

npm i https://pkg.pr.new/@emdash-cms/registry-client@2416

@emdash-cms/registry-lexicons

npm i https://pkg.pr.new/@emdash-cms/registry-lexicons@2416

@emdash-cms/registry-verification

npm i https://pkg.pr.new/@emdash-cms/registry-verification@2416

@emdash-cms/sandbox-workerd

npm i https://pkg.pr.new/@emdash-cms/sandbox-workerd@2416

@emdash-cms/x402

npm i https://pkg.pr.new/@emdash-cms/x402@2416

@emdash-cms/plugin-ai-moderation

npm i https://pkg.pr.new/@emdash-cms/plugin-ai-moderation@2416

@emdash-cms/plugin-atproto

npm i https://pkg.pr.new/@emdash-cms/plugin-atproto@2416

@emdash-cms/plugin-audit-log

npm i https://pkg.pr.new/@emdash-cms/plugin-audit-log@2416

@emdash-cms/plugin-color

npm i https://pkg.pr.new/@emdash-cms/plugin-color@2416

@emdash-cms/plugin-embeds

npm i https://pkg.pr.new/@emdash-cms/plugin-embeds@2416

@emdash-cms/plugin-field-kit

npm i https://pkg.pr.new/@emdash-cms/plugin-field-kit@2416

@emdash-cms/plugin-forms

npm i https://pkg.pr.new/@emdash-cms/plugin-forms@2416

@emdash-cms/plugin-webhook-notifier

npm i https://pkg.pr.new/@emdash-cms/plugin-webhook-notifier@2416

commit: f15551a

[Copilot]

Pull request overview

Updates the emdash-bot sandbox container image so agent-browser can launch a browser in the locked-down runtime environment by pre-installing Chrome for Testing during the image build and copying the resulting cache into the final sandbox stage.

Changes:

• Runs agent-browser install in the node-source build stage (where TLS/network downloads are expected to work).
• Copies the resulting /root/.agent-browser cache into the final cloudflare/sandbox image so no runtime browser download is needed.
• Updates the Dockerfile header comments to reflect that the image now includes a pre-baked browser for repro skills.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	emdash-demo-cache	f15551a	Aug 10 2026, 06:49 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	emdash-demo-do	f15551a	Aug 10 2026, 06:51 PM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	emdash-playground	f15551a	Aug 10 2026, 06:51 PM

[ascorbic]

Verification results for the baked Chrome:

In the built image (local, linux/amd64): agent-browser doctor reports 8 pass / 0 warn / 0 fail, including the live launch test ("Headless launch + about:blank in 3.84s"), and an open → get text → close round-trip works against the baked copy with no network access. The earlier failure mode is structural: the egress allowlist only passes GitHub/npm hosts, so the runtime Chrome download can never succeed — and additionally the intercepting proxy's CA isn't in the Rust binary's trust path, which is where the reported SSL errors came from.

In staging: the container is deployed (version 0ddcaed8). Re-runs of the two previously-blocked cases (#1272, #1124) plus a browser-leaning probe (#1607) all settled cleanly — though each legitimately resolved without the browser under the new needs-info/VFS-first discipline, so the staging-side browser path will get its first real exercise on the next admin investigation that needs the UI. No case attempted a runtime Chrome download (zero egress-block errors in the window).

~ 🤖 Claude Fable 5

[emdashbot]

The approach is the right fix: the emdash-bot sandbox egress allowlist only permits package/GitHub/npm-ish hosts, so agent-browser install cannot download Chrome for Testing at runtime. Baking the browser into the image during the node-source stage follows the existing multi-stage TLS pattern and solves the reported Chrome install failed failures for repro-admin/repro-public.

I checked the Dockerfile diff, the egress allowlist in infra/emdash-bot/.flue/cloudflare.ts, the repro skill docs, entrypoint.sh, and AGENTS.md conventions. No runtime code, API routes, DB queries, or i18n surface changes are involved, so the localization/authorization/query-count conventions do not apply here. The global agent-browser CLI install and symlink recreation already existed; the added RUN agent-browser install and COPY --from=node-source /root/.agent-browser /root/.agent-browser are consistent with the rest of the image and keep all TLS-dependent work in the node-source stage.

The build was not run here (no shell/CI available), but the change is straightforward and the author's runtime verification in the PR description aligns with the new steps. No blocking issues found.