sandbox-claude-inside
Run Claude Code INSIDE a ca-sandbox box (`--with-claude`). Routed to when the user wants an agent loop running against an isolated, ephemeral sandbox rather than the host. Authenticates via an env-injected CLAUDE_CODE_OAUTH_TOKEN with no host bind of ~/.claude; the image pins the CLI and disables the autoupdater; HOME is backed by a named volume so the .claude state persists across restart. Five gated phases — posture, image, token, run, teardown. The hard default is offline or Anthropic-domains-only egress, and the token volume is NEVER co-mounted with an untrusted-code run; both are enforced
npx skills add arbiterForge/codeArbiter --skill sandbox-claude-inside --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# sandbox-claude-inside Put Claude Code in the box, not the box on your machine. `--with-claude` runs the CLI inside a host-FS-isolated ca-sandbox container, authenticating from an env-injected token with no host bind of `~/.claude` — the mechanism proven by Spike B (`.codearbiter/spikes/ca-sandbox-claude-auth.md`, CONFIRM-07). It is the deliberately-hardened lane: a token in a box is stealable, so the posture is locked down by construction (offline or Anthropic-only egress, token volume never shared with untrusted code), never left to operator discipline. ## Pre-flight Read these, or STOP and surface the gap — never guess the token source, the egress posture, or the persistence mechanism: - `${CLAUDE_PROJECT_DIR}/.codearbiter/spikes/ca-sandbox-claude-auth.md` — the proven auth path (env token → real `401` on a dummy), the named-volume HOME persistence mechanism, and the load-bearing caveat that fixes the hard default. - `${CLAUDE_PROJECT_DIR}/.codearbiter/spikes/ca-sandbox-egress.md` — why the egress allowlist is EXPERIMENTAL (CDN drift + DNS-exfil hole), so `offline` is the only GUARANTEED posture for a token-bearing box. - `${CLAUDE_PROJECT_DIR}/.codearbiter/decisions/0007-secon
- Pre-flight
- Phase 1 — Posture · gate: BLOCK
- Phase 2 — Image · gate: BLOCK
- Phase 3 — Token · gate: BLOCK
- Phase 4 — Run · gate: BLOCK
- Phase 5 — Teardown · gate: BLOCK
- Hard rules
What does the sandbox-claude-inside skill do?
Run Claude Code INSIDE a ca-sandbox box (`--with-claude`). Routed to when the user wants an agent loop running against an isolated, ephemeral sandbox rather than the host. Authenticates via an env-injected CLAUDE_CODE_OAUTH_TOKEN with no host bind of ~/.claude; the image pins the CLI and disables the autoupdater; HOME is backed by a named volume so the .claude state persists across restart. Five gated phases — posture, image, token, run, teardown. The hard default is offline or Anthropic-domains-only egress, and the token volume is NEVER co-mounted with an untrusted-code run; both are enforced
How do I install it?
Run `npx skills add arbiterForge/codeArbiter --skill sandbox-claude-inside --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From arbiterForge/codeArbiter, a repository with 138 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.