Add Amp sandbox image

[SystemSculpt]

Summary

• add a hidden Amp sandbox image built on the standard Blaxel sandbox API
• install a pinned Amp CLI through a checksum-verified copy of Amp's official installer
• include Git, Python, and ripgrep for coding workflows
• add Amp to the manual sandbox build selector

Why

This gives Blaxel a provider-owned Amp runtime path comparable to the existing Codex and Claude Code sandbox images. Users can start Amp without installing the CLI during each sandbox session.

Verification

• built the image for linux/amd64
• verified the pinned installer checksum before execution
• verified the pinned Amp version, Python, Git, ripgrep, and sandbox API binary
• started the image and passed the sandbox API health check
• ran a live Amp task in a Blaxel sandbox with structured output
• put the sandbox in standby, reconnected through a new SDK instance, and continued the same Amp thread
• verified the exact repository changes after continuation

Release gate

This PR prepares the image but keeps the template hidden. Do not publish or unhide the image until ENG-4628 records Amp's written permission for image redistribution and branding.

No Amp outreach is included in this PR.

Linear: ENG-4614, ENG-4629

---

Note

Adds a hidden Amp sandbox image with pinned Amp CLI version, SHA-256 checksum verification of the installer script, and standard sandbox-api entrypoint. Includes workflow selector entry and template metadata.

^{Written by Mendral for commit e57408b.}

[mendral-app]

Needs attention — 1 issue in 1 file

The PR cleanly follows the established sandbox image pattern (hub/codex/Dockerfile is nearly identical in structure). Base image is digest-pinned, Amp version is pinned, and the template is correctly marked hidden. The one notable difference from the Codex image is that Amp is installed via a remote shell script rather than a package manager with built-in integrity verification — worth a supply-chain hardening step.

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.

<assessment>
The PR cleanly follows the established sandbox image pattern (`hub/codex/Dockerfile` is nearly identical in structure). Base image is digest-pinned, Amp version is pinned, and the template is correctly marked hidden. The one notable difference from the Codex image is that Amp is installed via a remote shell script rather than a package manager with built-in integrity verification — worth a supply-chain hardening step.
</assessment>

<file name="hub/amp/Dockerfile">
<issue location="hub/amp/Dockerfile:20">
The install script is fetched over HTTPS without integrity verification. If `ampcode.com/install.sh` is ever compromised or serves different content, malicious code runs in the image build. The `grep -F` check only validates the *version string* in the resulting binary, not the integrity of the installer itself. Consider checksumming the script or the installed binary against a known-good hash. Confidence: medium — the risk is real but depends on threat model and the transient nature of build environments.
</issue>
</file>

_{Tag @mendral-app with feedback or questions. View session}

[cursor]

Stale comment

[mendral-app]

🧪 Testing Guide

What this PR addresses

Adds a new Amp sandbox image to the Blaxel sandbox catalog, comparable to existing Codex and Claude Code sandbox images. The image is built on the standard Blaxel sandbox API (sandbox-api), installs a pinned Amp CLI version (0.0.1786305972-ge46792) via the official installer, and includes Git, Python, and ripgrep for coding workflows. The image is marked as hidden in the template metadata.

Steps to verify

Since this is a new container image (infrastructure/config change), there are no user-facing reproduction steps. Instead, verify the following:

1. Docker build succeeds for linux/amd64:

   cd hub/amp
   docker build --platform linux/amd64 -t sandbox-amp:test .

2. Pinned Amp CLI is correctly installed and on PATH:

   docker run --rm sandbox-amp:test amp --version
   # Should output version containing "0.0.1786305972-ge46792"

3. Required tools are present:

   docker run --rm sandbox-amp:test bash -c "git --version && python --version && rg --version"

4. sandbox-api entrypoint starts correctly:

   docker run --rm -p 8080:8080 sandbox-amp:test &
   # Verify the API is listening on port 8080
   curl -s http://localhost:8080/health || curl -s http://localhost:8080/

5. Installer integrity check: Confirm the AMP_INSTALLER_SHA256 in the Dockerfile matches the actual checksum of https://ampcode.com/install.sh at the time of build.

6. CI workflow updated: Confirm amp appears in the manual build selector dropdown in .github/workflows/build.yaml.

What to verify (expected behavior)

• The image builds without errors and the Amp version assertion in the Dockerfile (grep -F) passes.
• amp, git, python, and rg are all accessible from the default PATH.
• The container starts with sandbox-api as the entrypoint and exposes port 8080.
• template.json is valid JSON with "hidden": true, meaning it won't appear in the public catalog until intentionally revealed.
• The manual workflow dispatch in .github/workflows/build.yaml now includes amp as a selectable option.

Note

Posted by PR Testing Guide · Tag @mendral-app with feedback.

[mendral-app]

Supply Chain Security Review

✅ Approve — 1 finding in 1 file

Dockerfile uses good practices: node:24-slim is digest-pinned, and the remote installer script is verified with a SHA-256 checksum before execution. The ghcr.io/blaxel-ai/sandbox:${SANDBOX_VERSION} stage defaults to latest but this is an internal image parameterized via build arg, consistent with the project's existing patterns.

_{Tag @mendral-app with feedback or questions. View session}

[mendral-app]

maintainability (P3), medium confidence: The SANDBOX_VERSION build arg defaults to latest, a mutable tag. Consider pinning to a digest for reproducible builds, or documenting that CI always overrides this arg.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At hub/amp/Dockerfile, line 1:

<issue>
The `SANDBOX_VERSION` build arg defaults to `latest`, a mutable tag. Consider pinning to a digest for reproducible builds, or documenting that CI always overrides this arg.
</issue>

[mendral-app]

LGTM

All previous supply-chain concerns are addressed: the installer script is now checksummed before execution (sha256sum -c), the Node base image is digest-pinned, and the Amp version is verified post-install. The SANDBOX_VERSION=latest pattern matches the established project convention. No new issues in the update.

_{Tag @mendral-app with feedback or questions. View session}