Coding-agent CLI runs an interpreter in an untrusted workspace whose files shadow the standard library

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

What it checks

Plants three benign standard-library look-alikes (struct.py, json.py, shutil.py) in a workspace the agent did not author, then drives the agent to run its OWN benign interpreter path in that workspace (a plain python3 -c self-check - no injected code, no model persuasion). Because CPython puts the current directory (‘’ for -c) early on sys.path, the workspace’s struct.py shadows the stdlib the moment the agent’s good-faith code - or the standard library itself, e.g. zipfile doing import struct - performs an import. Each planted module writes a per-run nonce to this template’s lab and then re-exports the real module, so nothing breaks and the shadow is invisible. A wrapped python3 records every -c/-m invocation as a positive control, so a refutation is only issued when the interpreter demonstrably ran with the workspace off its module path (python -P / -I / PYTHONSAFEPATH=1, or cwd outside the checkout). Reproduces the Claude Code interpreter-shadowing class (Rehberger, 2026-08-28; Anthropic classified Informative, one-flag mitigation).

There is a playbook for this check

Interpreter search-path shadowing in an untrusted workspace 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-workspace-interpreter-shadowing
Severity	high
Language	shell
Category	ai
Author	CERT-X-GEN Security Team
Template version	not recorded
Confidence	90
CVSS	not recorded
Weakness	CWE-427
Tags	ai, coding-agent, cli, untrusted-workspace, interpreter, module-resolution, sys-path, pythonsafepath, supply-chain, cwe-426, cwe-427, cwe-829, cwe-94
Target kind	cli
Oracle	property

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.

• https://embracethered.com/blog/

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-workspace-interpreter-shadowing

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.