Skip to content

provider: add CAPE SandboxProvider backend (assumed CLI contract)#155

Merged
Meirtz merged 1 commit into
masterfrom
feat/cape-provider
Jul 22, 2026
Merged

provider: add CAPE SandboxProvider backend (assumed CLI contract)#155
Meirtz merged 1 commit into
masterfrom
feat/cape-provider

Conversation

@Meirtz

@Meirtz Meirtz commented Jul 22, 2026

Copy link
Copy Markdown
Collaborator

Summary

New agentix-provider-cape plugin: a SandboxProvider that maps one Agentix sandbox onto one long-lived request inside a dedicated CAPE session (CAPE is a lease-based GPU pool whose sessions survive across commands with a persistent workspace). The agent sandbox is a CAPE session: persistent workspace, on-demand GPUs.

  • CapeProviderConfig fully defaulted (zero-arg construction for the plugin registry); token from file or env, read per operation, 0o077 file-mode gate, token redacted from any subprocess output that can reach exception text.
  • _CapeCli is the single class holding the assumed run/status/logs/cancel verb surface — the contract is reverse-documented from a sibling project's adapter of the same CLI and has never been checked against a real cape binary. The README carries a prominent Contract status section and the verification checklist for when the real CLI arrives.
  • Endpoint discovery is serial-session friendly: the boot script prints an AGENTIX_ENDPOINT marker to stdout before exec'ing the bundle bootstrap; discovery polls cape logs on the one server request (no concurrent in-session commands), then health-probes with a raw TCP client. Transient status/logs failures tolerated up to a configurable consecutive limit.
  • Lifecycle discipline: shielded initial submit (cancellation can still harvest the request id and cancel it); kill + bounded reap on subprocess timeout/cancel; delete() retains bookkeeping until cancel is confirmed (retryable) and never raises; per-sandbox runtime ports from a configurable range.
  • Deliberately out of scope (documented): BundleDeployer/bundle transport to CAPE nodes (SandboxConfig.bundle is an opaque node-visible path); recovery of in-process bookkeeping after a crash (session-key naming convention is the server-side cleanup handle).

Review process

Implementation went through an adversarial review (4 lenses — lifecycle/leaks, asyncio subprocess discipline, contract fidelity, tests & conventions — each finding challenged by two independent refuters): 22 confirmed findings, all fixed or explicitly documented as known limitations. Notably the endpoint discovery was redesigned (originally a concurrent in-session control request, which contradicts the serial RUNNING_COMMAND ↔ CACHED_IDLE session model) and the submit/cancel windows were closed.

Testing

  • uv run pytest plugins/providers/cape/tests -q24 passed (fake cape executable with argv JSONL recording + env fault injection; loopback /health server; multi-sandbox classification; discovery retry/timeout; token hygiene; delete retry semantics; real sh -c boot-script round-trip)
  • uv run pytest tests/ plugins/ -q713 passed, 1 skipped, 6 deselected, 22 xfailed
  • uv run ruff check . → clean; uv run pyright0 errors; uv lock --check → current

🤖 Generated with Claude Code

Adds agentix-provider-cape: a SandboxProvider that maps one Agentix
sandbox onto one long-lived request inside a dedicated CAPE session
(CAPE is a lease-based GPU pool whose sessions survive across commands
with a persistent workspace). The agent sandbox *is* a CAPE session:
persistent workspace, on-demand GPUs.

Design:
- CapeProviderConfig is fully defaulted (zero-arg construction for the
  plugin registry); credentials come from a token file or env var, read
  per operation, with a 0o077 file-mode gate and redaction of the token
  from any subprocess output that can reach exception text.
- _CapeCli is the single class holding the assumed run/status/logs/
  cancel verb surface. The contract was reverse-documented from a
  sibling project's adapter of the same CLI and has never been checked
  against a real cape binary; the README carries the verification
  checklist for when the real CLI arrives.
- Endpoint discovery is serial-session friendly: the boot script prints
  an AGENTIX_ENDPOINT marker to stdout before exec'ing the bundle
  bootstrap, and discovery polls cape logs on the one server request
  (no concurrent in-session commands), then health-probes with a raw
  TCP client. Transient status/logs failures are tolerated up to a
  configurable consecutive limit.
- Lifecycle discipline: the initial submit is shielded so cancellation
  can still harvest the request id and cancel it; subprocess timeout and
  cancellation paths kill and reap with bounded waits; delete() retains
  bookkeeping until a cancel is confirmed (retryable) and never raises;
  per-sandbox runtime ports come from a configurable range.
- Deliberately out of scope: BundleDeployer / bundle transport to CAPE
  nodes (SandboxConfig.bundle is an opaque node-visible path), and any
  recovery of in-process bookkeeping after a crash (documented, with a
  session-key naming convention as the server-side cleanup handle).

24 plugin tests drive a fake cape executable (argv recorded as JSONL,
fault injection via env vars) plus a loopback /health server: run-face
assertions, multi-sandbox classification, discovery retry/timeout,
health timeout, token hygiene, delete retry semantics, and real sh -c
execution of the boot script round-tripped through the endpoint parser.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
@Meirtz
Meirtz force-pushed the feat/cape-provider branch from 0c3587a to 714902d Compare July 22, 2026 19:32
@Meirtz
Meirtz merged commit 6494bfa into master Jul 22, 2026
5 checks passed
@Meirtz
Meirtz deleted the feat/cape-provider branch July 22, 2026 19:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant