Agent sandbox contains the process but not the files it writes - deferred consumers execute agent-authored surfaces after the sandbox exits

coding-agent-sandbox-trust-handoff is a high severity check in the ai category, written in shell. Its source is templates/ai/coding-agent/coding-agent-sandbox-trust-handoff.sh in cert-x-gen-templates.

What it checks

Runs a synthetic sandboxed agent-stub that writes a benign decoy marker into each deferred-consumer surface (.claude/settings.local.json hooks, a venv interpreter shim, a .git/config diff-tool entry, .vscode/tasks.json, and a non-standard git hooks dir), one of them landed through allow-list flag mutation (git show –output=./.git/config) past a protected path. Phase 1 first PROVES the sandbox is real - a direct out-of-workspace escape write is blocked. Phase 2 runs AFTER the sandbox exits and triggers each unsandboxed consumer. CONFIRMED when a planted marker executes post-exit (a nonce sentinel appears) despite the boundary having held; REFUTED when every present consumer refuses the agent-authored surface (trust downgraded at the handoff); SKIP when the target does not confine the process (no boundary) or no consumer surface is present. The finding lives in a SECOND phase a single-pass scanner is never present for.

There is a playbook for this check

Agent sandbox trust-handoff escape (deferred execution of agent-written files) sets out the use case, the probe flow, the oracle, and the fixture that proves it in both directions.

Header

Field	Value
Id	coding-agent-sandbox-trust-handoff
Severity	high
Language	shell
Category	ai
Author	CERT-X-GEN Security Team
Template version	not recorded
Confidence	90
CVSS	not recorded
Weakness	CWE-668
Tags	ai, coding-agent, cli, sandbox-escape, trust-boundary, deferred-execution, two-phase, post-exit, cwe-668, cwe-693, cwe-829
Target kind	cli
Oracle	property, detector

Conventions of the repository, not fields the engine reads

@target_kinds and @oracles are documented in the templates repository’s contribution guide, and cxg’s annotation parser does not carry them into a template’s metadata. Nothing at scan time selects on them. The annotation header schema is every field the parser does read.

References

Declared in the header. cxg parses @references and then discards it, and nothing at scan time reads it, so this is the only place the links a template cites are surfaced.

• docs/playbooks/coding-agent-sandbox-trust-handoff.md

Run it

To see what the copy on your machine says about itself, and to confirm it is installed at all:

cxg template info coding-agent-sandbox-trust-handoff

The id it prints is the one to pass anywhere a template is selected. See cxg template for the rest of the subcommand, Scan a target for running a scan, and A match is not a finding for how to read what comes back.

Related

• Template catalog is the whole corpus.
• ai is the rest of this category.
• Templates by weakness class groups checks by the defect they look for.
• Contribute a template is the route from a check you needed and could not find to a merged one.