A repository can pass review and still be dangerous. That is the uncomfortable lesson from a June 2026 proof of concept by 0DIN, Mozilla’s AI security research program, against Claude Code: the malicious payload did not live in the GitHub repo at all.

It arrived at runtime.

The PoC targeted Claude Code specifically. But the structural condition it exploits — an agent with shell access being asked to set up unfamiliar code — is not unique to Claude Code. Any AI coding agent that reads project instructions and executes shell commands operates in the same trust boundary.

TL;DR

  • 0DIN demonstrated an attack where a normal-looking repository led to command execution through trusted setup behavior — using Claude Code as the test case.
  • The payload was fetched from a DNS TXT record, so static review of the repo would not show the final command.
  • The structural condition behind the attack — shell access combined with autonomous setup behavior — applies to any AI coding agent, not just Claude Code. No separate PoC is needed to confirm that the risk category is real.
  • Treat unfamiliar repositories like hostile build inputs regardless of which agent you use: isolate them, restrict egress, review setup scripts, and audit agent permissions.

What 0DIN Showed

0DIN’s post, published on June 15 and updated on June 25, 2026, describes a proof of concept where Claude Code was asked to get a freshly cloned project running. The repository itself did not contain the reverse shell payload. Instead, the setup path pulled a value from a DNS TXT record and executed what came back.

That detail matters. A reviewer sees a repository. A scanner sees repository contents. The agent sees project instructions, setup notes, and an error-handling path. None of those views necessarily include the final command that runs on the developer workstation.

The attack chain is simple enough to be useful:

  1. A developer opens an unfamiliar repository with an AI coding agent.
  2. The agent reads the project’s setup instructions and attempts to run the project.
  3. A setup script performs a DNS TXT lookup for configuration.
  4. The returned value is treated as executable input.
  5. The resulting process runs as the developer’s local user.

This is not a claim that the technique is being exploited at scale. The public evidence supports a proof of concept. But the security lesson is real: agentic coding tools can connect documentation, shell commands, package installation, error recovery, and network access into one action path.

The DNS TXT channel is also not the point. The same outcome is achievable through post-install npm scripts, Makefile targets, CI configuration hooks, or any mechanism that runs code during project setup. The delivery channel changes; the trust boundary problem does not.

Not Just Claude Code

0DIN’s proof of concept targeted Claude Code. Only Claude Code has a public, confirmed PoC for this specific attack vector. What the other tools share is the same structural property: shell access inside the developer’s trust boundary, on code that hasn’t been fully reviewed.

AgentShell accessNotes
Claude CodeBash tool, approval per commandPoC confirmed; --dangerously-skip-permissions removes all prompts
GitHub Copilot AgentVS Code integrated terminalRuns with full IDE process permissions and ambient credentials
CursorTerminal tool in Composer”Yolo mode” skips confirmation prompts in agent sessions
Windsurf (Codeium)Cascade terminal toolSession-scoped approval within developer environment
AiderCLI shell with git write access--yes disables all interactive confirmations
DevinFull VM shellFully autonomous by design; isolation enforced at VM boundary
Amazon Q DeveloperTerminal in agent modeDeveloper AWS credentials typically present in the environment

The table reflects documented architectural properties, not confirmed exploits against each tool. The shared risk is structural: the more a tool can do autonomously, the more a setup path in an untrusted repository can do through it.

Why Clean Repos Are Not Enough

Traditional code review assumes the dangerous thing is in the code you reviewed. That assumption fails when the dangerous thing is fetched during setup.

This is already familiar in software supply chain security. Post-install scripts, build hooks, generated code, remote templates, and dependency resolution all move behavior outside the obvious source files. AI coding agents add another layer: they can decide which commands to run next after reading project text, tool output, and error messages.

The result is a split-brain attack surface:

LayerWhat looks normalWhat can go wrong
RepositoryREADME, setup script, project filesInstructions steer the agent into a risky path
NetworkDNS lookup or package fetchRuntime payload changes without a commit
WorkstationShell command from the agentRuns with the developer’s files, tokens, and SSH context nearby

The DNS TXT trick is especially awkward for defenders. DNS often gets treated as infrastructure noise. TXT records are also legitimate for SPF, DKIM, domain verification, and service configuration. A single TXT lookup is not automatically malicious. The problem is the next step: using the returned value as code.

The Agent Is a Privilege Multiplier

Every agent in the table above inherits the trust context of the shell it runs in. Claude Code documents this distinction explicitly: permission modes decide whether a tool call is allowed; isolation decides what that call can reach after it runs. The same principle applies to every other agent, stated or not.

If a session runs as the developer’s local user, with a shell that has access to cloud credentials, SSH keys, and git remotes, then every command the agent executes — including those triggered by setup instructions in an untrusted repository — runs inside that same trust boundary.

The agent does not need to be malicious. It only needs to be helpful in the wrong place.

Some tools have documented modes that reduce confirmation friction:

  • Aider’s --yes flag is designed for automation pipelines. Used interactively against unfamiliar code, it removes the only review step between the project’s setup instructions and your shell.
  • Cursor’s yolo mode skips terminal command confirmations inside agent sessions. The documentation describes this as intended for trusted workflows.
  • Devin is fully autonomous by design. Its value proposition is “run this and come back to a working result.” At that level of autonomy, the blast radius is controlled at the VM boundary, not by any in-tool permission gate.

These are documented features, not vulnerabilities. The risk is in applying them to untrusted repositories. The pattern is consistent: the more autonomous the agent, the more critical the isolation layer becomes.

What To Detect

Defenders should not try to detect “AI did something bad” as a single event. Watch the behaviors around the developer workstation and build environment:

  • Shell commands that pipe remote or dynamic content into an interpreter.
  • DNS TXT lookups from developer machines followed by shell execution, package installation, or new outbound connections.
  • Unexpected child processes from package managers, test runners, build tools, or setup scripts.
  • New outbound connections immediately after a repository clone or first-time setup.
  • Reads of .env, cloud credential files, SSH keys, npm tokens, PyPI tokens, or Kubernetes configs during setup.

For endpoint logging, the useful pattern is sequence, not one magic indicator:

git clone -> agent/session starts -> setup command -> DNS TXT lookup -> shell child process -> outbound connection

For network teams, DNS TXT volume from developer endpoints is worth baselining. It should not be zero, but it should be explainable.

For teams with a SIEM, a Sigma rule targeting the DNS TXT step:

title: DNS TXT Query Spawned by Build or Setup Process
id: f3a9b1c7-e52d-4d8a-9f31-0b2e8c6d4a71
status: experimental
description: >
  Detects a DNS TXT lookup issued by a build tool, package manager, or setup
  script. TXT records are rarely needed for builds — this is a common
  runtime payload delivery vector.
author: Hive Security
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    CommandLine|contains:
      - 'nslookup -type=TXT'
      - 'nslookup -qt=TXT'
      - 'dig TXT'
      - 'host -t txt'
    ParentImage|endswith:
      - '/npm'
      - '/pip'
      - '/node'
      - '/make'
      - '/python3'
      - '/sh'
  condition: selection
falsepositives:
  - Domain ownership validation in CI scripts
  - SPF/DKIM verification tooling
level: medium
tags:
  - attack.execution
  - attack.t1071.004

Correlate this with a new outbound connection or interpreter spawn within the same session to raise confidence.

How To Use Coding Agents Safely

The answer is not “never use AI coding agents.” The answer is to stop treating an agent session as a harmless editor tab.

Start with these controls:

  1. Run unfamiliar repositories in a VM, dev container, or equivalent isolated environment.
  2. Keep cloud credentials, SSH keys, production kubeconfigs, and publishing tokens out of that environment by default.
  3. Disable or tightly restrict network egress when evaluating untrusted code.
  4. Review setup scripts before allowing the agent to run them.
  5. Deny or ask on network-capable shell tools such as curl, wget, and similar fetch paths unless the domain and command are expected.
  6. Audit your agent’s accumulated permission rules — /permissions in Claude Code, workspace trust settings in Copilot and Cursor, or session allow lists in others. Project-level rules accumulate quietly across sessions.
  7. Avoid --dangerously-skip-permissions on the host. Use it only inside a container or VM designed to be disposable.

For teams, managed settings are the difference between a recommendation and a control. Standardize permission rules, require isolation for untrusted repos, and log agent activity the same way you log other developer automation.

The Real Takeaway

The clean repo trap is not about one tool or one clever DNS payload. It is about a trust model that did not survive contact with autonomous setup behavior.

Developers used to clone first and ask questions later. AI coding agents make that habit more dangerous because they can keep going after the first command succeeds, after the first error appears, and after the first “documented fix” looks reasonable.

If a repository is unfamiliar, the agent should be treated like a junior developer with shell access inside a quarantine lab: useful, fast, and absolutely not allowed to carry your production keys in its pocket.

Sources