feat: integrate openclaw/crabbox as AgentENV sandbox client

[zozo123]

Summary

• Integrate the upstream openclaw/crabbox CLI as an AgentENV sandbox client through Crabbox's built-in e2b provider
• Add a safe config/crabbox.example.yaml containing only project-scoped template/workdir settings (no endpoint or credentials)
• Document the required AgentENV host-based sandbox proxy domain, wildcard DNS, TLS, environment variables, lifecycle commands, limits, and troubleshooting
• Add CI that installs pinned Crabbox v0.40.0 with SHA-256 verification, loads the real config, and exercises list/create/connect/archive-sync/process/delete against a strict E2B contract server
• Keep the integration wrapper-free: users install and run upstream crabbox directly

Important deployment requirement

Crabbox's e2b provider sends file and process traffic to https://{port}-{sandboxID}.{domain}; it does not read E2B_SANDBOX_URL. AgentENV must therefore advertise [sandbox_proxy].domains[0] (or AENV_SANDBOX_PROXY_DOMAINS) and expose wildcard DNS + TLS for that domain. A loopback-only E2B_API_URL is sufficient for doctor and list, but not for warmup or run.

Validation

• Crabbox v0.40.0 release asset checksum verified against the upstream release
• config/crabbox.example.yaml loaded by Crabbox with required 0600 permissions
• E2B contract smoke: authenticated list, sandbox create/connect, archive upload, envd process stream, command output, and one-shot delete
• actionlint -no-color .github/workflows/crabbox.yml
• ruff check and ruff format --check for the contract server
• pyright scripts/tests/crabbox-e2b-contract-server.py
• make fmt
• make docs
• Upstream Crabbox delegated-run sanity smoke through Islo
• Live crabbox run --provider e2b against a KVM-backed AgentENV deployment with wildcard DNS/TLS (requires deployment infrastructure not available in this checkout)

[zozo123]

Islo verification (openclaw/crabbox)

Validated upstream crabbox against Islo while preparing this PR (no in-repo wrapper):

1. islo api-key create … --show → export ISLO_API_KEY=…
2. crabbox doctor --provider islo → ok (auth=ready)
3. crabbox list --provider islo --json → ok
4. crabbox run --provider islo --islo-vcpus 2 --islo-memory-mb 2048 --islo-disk-gb 10 --no-sync -- echo crabbox-islo-ok → pass (crabbox-islo-ok, lease slug quick-crab)

AgentENV usage remains --provider e2b + E2B_API_URL / config/crabbox.example.yaml.

[github-actions]

✅ OpenCodeReview: No supported files changed.

[github-actions]

This job has no timeout even though it performs network downloads, runs a background server, invokes remote provider operations, and may allocate an Islo environment. A stalled operation can consume the runner until GitHub's platform limit and potentially retain remote resources. Add a repository-appropriate timeout-minutes value (and consider command-level timeouts for remote lifecycle calls).

Suggestion:

Suggested change

	integrate:
	runs-on: ubuntu-latest
	integrate:
	runs-on: ubuntu-latest
	timeout-minutes: 30

[github-actions]

This third-party action is referenced by a mutable tag rather than a reviewed full commit SHA. If the tag or upstream repository is compromised, arbitrary code can execute and persist until the later secret-bearing Islo steps. Pin taiki-e/install-action to a full commit SHA and specify an explicit mdBook version for reproducible installs.

[github-actions]

This secret-bearing step runs in the same job after pull-request-controlled code has been checked out and executed. Secrets are available to same-repository PRs, and an earlier malicious script can persist changes through $GITHUB_ENV/$GITHUB_PATH, replace executables, or otherwise compromise later steps before this secret is injected. Move the Islo smoke to a separate job with a fresh checkout and gate it to a trusted event/ref (for example, a push to main or an explicitly trusted dispatch); do not expose ISLO_API_KEY in any job that executes PR code.

[yingdi-shan]

Thanks for your contribution! Integrations with other tools can improve AgentENV's usability, so this is a welcome addition. That said, I think we should keep this minimal: add a short section on how to configure it, plus a link, rather than updating the README and docs extensively or modifying the code for the integration test.

[zozo123]

Thanks — that's a fair call, the PR was doing far too much. Pushed a commit that cuts it down to what you asked for.

Removed:

• .github/workflows/crabbox.yml and the 323-line mock E2B server it drove. It only ever tested upstream Crabbox against a fixture in this repo, never AgentENV itself, and the existing e2e suites already cover the E2B surface against the real server.
• config/crabbox.example.yaml — the config is a handful of env vars, so it's an inline fenced block in the doc instead of a checked-in file.
• All edits to README.md, docs/src/configuration/env-vars.md, docs/src/getting-started/overview.md and docs/src/troubleshooting/common-issues.md are reverted to their upstream text. The "recommended sandbox client" wording is gone.

What's left is one 34-line docs/src/integration/crabbox.md (three env vars, two commands, and the one non-obvious constraint — the e2b provider ignores E2B_SANDBOX_URL and needs the host-based sandbox proxy domain), plus a single link each from the README's existing E2B section, the overview table, the quickstart list, and e2b.md.

Net is +43/-0 across 6 files, down from +836/-7 across 12, with no upstream lines deleted anywhere. Happy to fold the page into e2b.md as a ## Crabbox subsection instead if you'd prefer no new page.