Verify the sandbox

From your project on the host:

claude-sandbox verify

The same command works in a container terminal. It runs the installed battery directly through the sandbox wrapper: no model, agent login or prompt is needed. To check another agent’s filesystem profile:

claude-sandbox verify --agent codex
claude-sandbox verify --agent pi

The selected profile uses the normal workspace, configuration, mounts and network jail. Its agent must be installed, but is not started. Inside an existing sandbox, claude-sandbox verify checks that current sandbox instead.

Read the result

Every check should report PASS. A failure names the affected defence. The command exits with the battery’s failure count; zero means all checks passed. Namespace setup failures also return nonzero.

Verification checks explains the checks and their limits. Checks 19–20 inspect network routes, but treat a disabled jail as a pass with a note; read those notes as well as the PASS count.

Full adversarial audit

The shipped verify-sandbox skill adds an expanded adversarial audit in Claude, Codex and Pi. Ask the agent to use that skill (or invoke /verify-sandbox in Claude). It runs the installed battery first, then tries ten adversarial probes only if all checks pass. No source checkout is needed. The workflow lives in skills/verify-sandbox/SKILL.md.

After updating an existing installation, start a fresh agent session to get the new skill mount. Remove obsolete personal verify-sandbox commands or skills so there is only one maintained audit workflow.

Ordinary verification uses the installed battery and needs no source checkout. There are no automatic session or prompt hooks.