Repository quarantine for coding agents means opening an unknown project without immediately giving the agent broad shell access, network, secrets, MCP, or install scripts. The agent can read and explain first. Execution comes later, after the repository earns more trust.

On June 25, 2026, 0DIN published "Clone This Repo and I Own Your Machine", showing a normal-looking repository that led Claude Code to a reverse shell through a routine error, a setup script, and DNS TXT (0DIN, "Clone This Repo and I Own Your Machine", 2026). The defense starts before setup.

Practical summary

  • Open unknown repos in read mode and without secrets.
  • Deny network and MCP until triage is done.
  • Run setup only in disposable, observable environments.
  • Promote permissions from evidence, not convenience.

Abstract diagram showing an isolated repository before it reaches a coding agent with no visible text.

Why did quarantine become part of agentic work?

In 2026, 0DIN described a chain where the malicious payload was not present in the repository and was fetched at runtime from a DNS TXT record (0DIN, "Clone This Repo and I Own Your Machine", 2026). Quarantine matters because code review cannot see what only appears after a command runs.

The uncomfortable part is that the agent was trying to help. It read instructions, hit an error, ran the suggested fix, and followed a chain that looked like normal installation. A tired human could read the same path as plausible.

This risk class is not just a suspicious file. It is the sequence of documentation, package error, helper script, network, and trust in the agent. Each piece looks small. The full chain changes the machine.

That is why quarantine starts before npm install, pip install, make setup, or any command suggested by the error itself. If the agent has not proven where the command leads, the command is untrusted input.

This builds on hooks for coding agents and MCP allowlists for coding agents. Hooks intercept action. Allowlists limit tools. Quarantine decides whether the repository leaves the cold zone.

Citable capsule: Repository quarantine is a pre-execution defense for coding agents. In 2026, 0DIN showed a payload outside the repository, loaded at runtime through DNS TXT; unknown project setup should therefore begin without network, secrets, or broad permission.

What stays blocked before the first execution?

In 2026, Claude Code security docs say web-fetching commands such as curl and wget are not auto-approved by default and prompt like other sensitive Bash commands (Claude Code Docs, "Security", 2026). Quarantine turns that behavior into project policy.

Block outbound network, secret variables, writes outside the temporary folder, MCP servers, and install commands until the agent produces a triage. That triage should identify setup scripts, package hooks, workflow files, native dependencies, and any command that fetches remote content.

The first agent request should be reading, not execution. Ask it to list entry points: package.json, pyproject.toml, Makefile, Dockerfile, CI workflows, install scripts, and first-run documentation. That inventory gives you a basis for the next command.

For long runs, I use RemoteCode to reduce repeated context in Codex and Claude Code agent sessions instead of dumping the same history into the main prompt. It is my own tool, so this is an editorial mention tied to context cost during long triage.

Denying network is not enough if the environment carries secrets. A local script can read .env, cloud tokens, or SSH keys. In quarantine, the environment starts clean and receives credentials only after the need is reviewed.

Citable capsule: The initial block should cover network, secrets, MCP, broad writes, and installation. Claude Code documents explicit approval for network commands; in unknown repositories, that rule should become the default operating mode before first execution.

How do you build a cold zone for Codex and Claude Code?

In 2026, Codex docs recommend workspace-write with on-request approvals as the lower-risk local automation preset, while full access combines danger-full-access with never (OpenAI Developers, "Sandbox", 2026). The cold zone chooses the conservative side.

Start with reading and manual approval. In Codex, avoid the full-access package for newly cloned repositories. In Claude Code, keep strict permissions and use Bash sandboxing when setup needs to move beyond reading.

A baseline contract can look like this:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

This file is not the whole defense. The real boundary is the environment: clone into a disposable folder, no .env, no inherited shell credentials, no sensitive Docker socket, no personal kubeconfig, and no MCP connected for convenience.

Use a container or virtual machine when setup must compile, download dependencies, or execute unknown binaries. Claude Code's own security docs recommend VMs for scripts and tool calls when interacting with untrusted content (Claude Code Docs, "Security", 2026).

Abstract flow showing triage, isolation, and gradual promotion for a coding agent with no visible text.

Practical experience: when I treat a repo as unknown, I ask for a script and risk map before running anything. Then I run the smallest verifiable command. It slows the first minutes, but it avoids turning install failure into implicit authorization.

Citable capsule: A cold zone for Codex and Claude Code combines initial reading, sandboxing, manual approval, and an environment without secrets. Codex docs distinguish workspace-write with on-request from full access; unknown repositories should earn permission promotion through evidence.

When should the repo move into normal execution?

In April 2026, the SWE-chat study reported 2.7 million events, more than 63,000 prompts, and more than 355,000 tool calls from real coding-agent interactions (arXiv, "SWE-chat", 2026). Promotion matters because tool use is now normal behavior, not an edge case.

Promote in phases. First, reading. Then local commands without network or broad writes. Next, installation inside a disposable container. Finally, normal execution only after scripts, dependencies, and external calls have a reviewable explanation.

The promotion rule should fit in one sentence: the agent gets more permission only when the previous phase produced understandable evidence. That evidence can be a script inventory, an empty diff, a domain list, or a short install log.

Do not promote because everyone is tired. The dangerous pattern is "just let it run and see." In an agentic workflow, running to see can trigger package hooks, post-install steps, native binaries, telemetry, or runtime-fetched commands.

Use a compact matrix:

Phase Agent can do Still blocked
Triage Read files and explain setup Network, secrets, and MCP
Simulation Run predictable local commands Install with remote scripts
Isolated execution Install in a disposable container Real credentials and deploy
Normal work Edit and test within scope Out-of-repo writes and broad secrets

Citable capsule: Phase-based permission promotion lowers risk because agent tool use already happens at scale. SWE-chat recorded 2.7 million events and more than 355,000 tool calls; every promotion should leave evidence of command, scope, and origin.

How does quarantine connect to CI and PR review?

In June 2026, GitHub extended security validation for third-party coding agents with CodeQL, dependency checks against the GitHub Advisory Database, and secret scanning (GitHub Changelog, "Security validation for third-party coding agents", 2026). Local quarantine and CI protect different moments.

Quarantine protects the machine before a PR exists. CI protects the repository after the agent creates a change. If setup already leaked a local token, no later CodeQL run can undo that leak.

Still, CI should carry the same contract. If a branch began from an unknown repo, put the evidence in the PR: environment used, network allowed or denied, secrets absent, commands run, and dependency alerts.

This connects to PR evals for coding agents in CI and self-correcting agent loops in CI. The difference is timing: quarantine decides what may run before CI becomes feedback.

Abstract matrix showing permission phases for coding agents with no visible text.

Citable capsule: GitHub validated third-party agents with CodeQL, dependency checks, and secret scanning in 2026, but that does not replace local quarantine. CI evaluates the PR; quarantine prevents unknown setup from compromising the workstation before a PR exists.

A quarantine checklist for the next repo

In May 2026, GitHub said Copilot code review had processed more than 60 million reviews and that more than one in five GitHub reviews involved an agent (GitHub Blog, "Agent pull requests are everywhere", 2026). That volume needs a checklist that is simple and repeatable.

Before asking "run the project", ask "map the project without executing." Then inspect install scripts, post-install hooks, network calls, native binaries, workflows, and agent configuration files. Only then choose the smallest safe command.

Use this flow:

  • Clone into a disposable directory with no inherited .env.
  • Start the agent in read mode or with manual approval.
  • Disable MCP until the repository origin is understood.
  • Ask for an inventory of scripts and setup commands.
  • Run installation in a container or VM when uncertain.
  • Promote permissions only with a short log and reason.
  • Delete the environment if a command fetches an unexpected payload.

Quarantine is not distrust of AI. It is the same discipline engineers already apply to dependencies, CI, and production. The difference is that agents can now connect documentation, error handling, shell, and network into a sequence that looks like normal work.

Citable capsule: The quarantine checklist exists because agentic review is already routine. GitHub reported more than 60 million Copilot code reviews; before expanding agents, teams should standardize reading, isolation, network, secrets, and permission promotion.

Frequently asked questions

Is quarantine needed for every repository?

No. In 2026, 0DIN showed a specific risk in unknown repositories with payload outside the code (0DIN, "Clone This Repo and I Own Your Machine"). Internal and recurring repos can use a more flexible profile, but a new project, tutorial, proof of concept, or chat link should start without network, secrets, and broad permission.

Can I trust the repo if scanners find nothing?

Not fully. In 2026, 0DIN showed a payload that was not in the repository and was fetched from DNS TXT at runtime (0DIN, "Clone This Repo and I Own Your Machine"). Code scanners can miss chains where each isolated piece looks normal. Quarantine observes execution, not only files.

Does workspace-write solve this by itself?

Not by itself. In 2026, Codex docs describe workspace-write with on-request approvals as a lower-risk local preset (OpenAI Developers, "Sandbox"). Teams still need to remove inherited secrets, unnecessary network, broad MCP, and untriaged setup commands.

When can MCP be enabled again?

After triage. In 2026, Claude Code documents trust verification for new MCP servers and first codebase runs (Claude Code Docs, "Security"). In an unknown repository, enable only necessary tools, keep scope narrow, and avoid sensitive credentials in the first cycle.

Sources

  • 0DIN, "Clone This Repo and I Own Your Machine", retrieved 2026-07-10, https://0din.ai/blog/clone-this-repo-and-i-own-your-machine
  • OpenAI Developers, "Sandbox", retrieved 2026-07-10, https://developers.openai.com/codex/concepts/sandboxing
  • OpenAI Developers, "Agent approvals & security", retrieved 2026-07-10, https://developers.openai.com/codex/agent-approvals-security
  • Claude Code Docs, "Security", retrieved 2026-07-10, https://code.claude.com/docs/en/security
  • Claude Code Docs, "Settings", retrieved 2026-07-10, https://code.claude.com/docs/en/settings
  • GitHub Changelog, "Security validation for third-party coding agents", retrieved 2026-07-10, https://github.blog/changelog/2026-06-09-security-validation-for-third-party-coding-agents/
  • arXiv, "SWE-chat: Coding Agent Interactions From Real Users in the Wild", retrieved 2026-07-10, https://arxiv.org/html/2604.20779v1
  • GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", retrieved 2026-07-10, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/