CLAUDE.md and Copyleft Code Reuse: What Instructions and Settings Can and Cannot Prevent

What CLAUDE.md actually does

CLAUDE.md is a rules file. It gives the model persistent context about a project, such as conventions, build commands and constraints. OWASP's secure coding guidance groups it with other rules files, including AGENTS.md and .cursorrules, and describes them as persistent steering that silently steers every future generation. It treats them as something to review, not as an enforcement mechanism.

An instruction such as "do not reuse GPL or AGPL code" therefore enters the model's context and may shift its output. It is not evaluated by anything outside the model. If the model misreads the instruction, weighs it against another one, or has no way to tell that a given output resembles licensed code, nothing stops the output from reaching the working tree. The instruction is a reasonable risk-reduction measure. It is not evidence that copyleft code was kept out.

What each control governs

The useful question for each mechanism is what it acts on and whether it acts outside the model's own reasoning. OWASP guidance places authorization and tool-call validation in trusted code, independent of how the model interprets a request. Applying that test gives the following picture.

• CLAUDE.md instructions: Governs model context. Probabilistic, because the model decides how to apply it. Cannot verify the licence or origin of any output. Produces no evidence.
• Permissions and allow/deny rules: Govern which tools, files and commands the assistant may use. Deterministic for the actions they name. They do not inspect the licence of code that is written or retrieved.
• Hooks: Run client-side logic at defined points in a session. Deterministic, and able to call external checks. Their licence coverage is whatever the team builds into them.
• Execution-path enforcement: Evaluates interactions and tool calls outside the model and applies allow, redact or block. Can act on origin and licence context and record the decision.

Why settings do not close the gap

Permissions and hooks restrict what the assistant can do: which files it can read or edit, which commands it can run, and which network retrieval it can attempt. That is valuable for limiting blast radius. It is not the same as knowing what a piece of code is. Copyleft terms attach to the source being accessed, as NIST's supply chain guidance notes about open-source projects generally. A permission rule can allow or deny a fetch, but it has no view of whether the fetched or generated text is derived from a GPL or AGPL project.

Approval prompts have the same limit. They put a human in front of certain commands, which is a user-mediated control, and a developer reviewing a file edit is unlikely to recognise licensed code by sight. Many developers also run agents with auto-accept enabled, in which case the agent operates with the developer's full permissions and the prompt is no longer a checkpoint.

CI gates help but are not sufficient by default. OWASP recommends failing pipelines on known dependency vulnerabilities and blocking very new packages, regardless of whether code was written by a person or an assistant. Those examples address vulnerabilities and package age. A licence rule has to be added and tested explicitly, and a scanner that matches against known licence data may not identify code that was reproduced and then modified.

Residual risk and evidence gaps

With instructions and settings alone, three risks remain. The first is reproduction: the assistant emits code that is derived from copyleft-licensed work, and nothing evaluates it. The second is retrieval: the assistant fetches code or adds a dependency under a copyleft licence, and the permission model sees only an allowed tool call. The third is configuration drift: rules files and assistant settings change, and the behaviour you documented is no longer the behaviour in effect. OWASP advises monitoring configuration changes across Claude Code, Cursor, Gemini CLI and VS Code, and putting rules files under code review and CODEOWNERS coverage.

The evidence gap matters as much as the control gap. When an auditor or counsel asks how a given change was checked, a CLAUDE.md file shows intent, and a settings file shows what the tool was permitted to do. Neither shows the origin or licence of the code that was actually produced, or what decision was made about it before merge.

Evidence to retain for each AI-assisted change

The evidence should let a reviewer reconstruct the licence decision without relying on anyone's memory. A practical minimum is the interaction or tool call that produced or retrieved the code, the origin and licence determination, the policy that was applied and its version, the outcome (allowed, redacted, blocked or escalated), who approved any exception, and a timestamp. It should be stored with defined retention and be reviewable before merge.

The record has to be generated by the enforcement point itself. A summary written afterwards by a developer or by the assistant is a statement, not evidence. Retention periods and residency requirements should be set by your own legal and compliance teams.

Where Trussed fits

Trussed is one option for the enforcement layer described above. It enforces policy in the execution path of coding assistants, alongside models, agents, tools and MCP servers, on individual interactions and tool calls. Policy outcomes include allow, redact, block, rate limit and escalation for human approval, and they are enforced at runtime, not reviewed after the fact.

For code, Trussed provides code provenance: the origin, licence and security context of code. The enforcement activity generates continuous audit-ready evidence, which is mapped to frameworks including NIST and the EU AI Act. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Trussed has run continuously in production at a regulated enterprise for more than 18 months.

Trussed does not replace CLAUDE.md, permissions or CI checks. Those remain useful for steering and scoping. Trussed addresses the part they cannot: checking what was actually produced and recording the decision.