Hacktron's walkthrough emphasizes that they didn't need a novel model jailbreak — they just planted instructions in a README, CONTRIBUTING guide, and source comments. The core failure is that Codex Cloud ingests repository content into its context window and executes on it as if the operator wrote it, meaning any tool-using agent that reads untrusted text inherits that text's goals.
The editorial reframes the story away from 'another jailbreak' and toward an architectural indictment: GPT-5-class models are getting harder to break directly, but that hardening is irrelevant when the agent can't distinguish trusted from untrusted input. This is presented as an unresolved problem for the whole category of tool-using agents, not a Codex-specific bug.
Hacktron demonstrates that even with no arbitrary outbound network, no long-lived credentials, and a small package-registry allowlist, they can chain npm config side effects, git push to an attacker-controlled fork on an allowlisted host, and DNS-subdomain encoding into a working exfiltration path. The point is that a 'deliberately conservative' sandbox still leaves enough covert channels to smuggle tokens out.
Hacktron is explicit that npm covert channels, git-push exfiltration, and DNS tunneling are all well-known individually. The write-up's contribution is showing they combine into a reliable exploit against a production agent from the lab 'that arguably takes alignment most seriously,' suggesting the industry underestimates chained low-severity primitives.
The editorial highlights that none of the gadgets are new in isolation and treats OpenAI's alignment reputation as the reason the result matters. If a lab with this much investment in safety still ships an agent breakable by a README, the composability problem is the industry's, not one vendor's.
Hacktron, a small AI-security shop, published a walkthrough of how they got OpenAI's Codex cloud agent — the hosted, sandboxed one that clones your repo and runs shell commands on your behalf — to leak data out of its own sandbox. The exploit didn't require a novel model jailbreak; it required a README.
The setup: Codex Cloud spins up an ephemeral container, pulls the target repository, and lets the model run bash, edit files, and open pull requests. OpenAI's sandbox is deliberately conservative — no arbitrary outbound network, a small allowlist of package registries, no long-lived credentials. Hacktron's proof-of-concept plants instructions inside project files (a README, a CONTRIBUTING guide, a source comment) that the agent will read as part of "understanding the codebase." Those instructions redirect the agent's goals: instead of, say, fixing a bug, it's told to grep the environment for tokens and smuggle them out through one of the sandbox's few permitted egress channels — package manager traffic, git operations against the allowlisted remote, or DNS lookups the resolver still honors.
The write-up walks through the specific gadgets: using `npm config` and package-install side effects as a covert channel, abusing `git push` to an attacker-controlled fork on the allowlisted host, and encoding stolen data into subdomains that hit a resolver the sandbox can't easily block. None of these are new tricks in isolation. The novelty is stitching them into a working exploit against a production agent from the lab that arguably takes alignment most seriously.
The interesting failure here isn't the model. GPT-5-class models are getting harder to jailbreak directly, and Codex refuses plenty of obviously malicious asks. The failure is architectural: the agent treats content it reads from disk with the same trust it gives instructions from the operator. Once you accept untrusted text into the context window of a tool-using agent, you have effectively granted the author of that text partial control over your tool calls. This is the indirect prompt injection problem Simon Willison has been shouting about for two years, and it keeps reappearing every time a new agent product ships.
Compare the mitigations across the field. Anthropic's Claude Code runs locally and defers to the human for shell commands by default; the blast radius is your laptop, but the human is in the loop for exfil-shaped actions. Cursor and Cline sit in a similar posture. OpenAI's Codex Cloud made a different bet: run the agent unattended in a sandbox, and rely on the sandbox — not the human — to be the trust boundary. That bet only pays off if the sandbox actually contains a hostile agent. Hacktron's post is a data point that it doesn't, at least not against a motivated attacker who controls a repository the agent will touch.
The community response on Hacker News was telling. The top-voted comments weren't "OpenAI screwed up" — they were "this is what everyone building agents is going to hit, and nobody has a clean answer." A few practitioners pointed out that the same class of bug lives in every code-review bot, every "summarize this PR" GitHub App, and every IDE plugin that pipes file contents into an LLM with tools attached. The industry has been shipping these products faster than it's been thinking about the threat model.
There's also a governance angle worth naming. OpenAI's own Preparedness framework talks about agentic risks, and the company has been vocal about wanting to lead on safe deployment of autonomous systems. Getting popped by a third-party researcher via a README is not a catastrophic outcome — nobody lost real money here, and Hacktron disclosed responsibly — but it does undercut the narrative that hosted, sandboxed agents are inherently safer than the local ones.
If you're evaluating or already running a coding agent, the practical takeaways are concrete. Assume every file in a cloned repository is potentially adversarial input, and design the agent's permissions accordingly. That means: no ambient credentials in the environment the agent can read (rotate anything that leaks, use short-lived tokens scoped to the specific task), no egress to hosts the agent can trigger writes on unless you've audited what data can end up there, and a hard human-in-the-loop gate for any action that touches production or leaves the sandbox.
If you're building an agent product, the lesson is that sandboxing is necessary but not sufficient. You need a data-flow analysis in your own head: what content enters the context window, what tools does the agent have, and what combinations of the two produce an exfil primitive? Package manager configuration, git remotes, and DNS are the obvious ones; less obvious are things like error messages that get logged to a remote observability backend, or PR descriptions that get posted to an external issue tracker. Every one of those is a potential channel if the attacker controls the text the agent reads.
For teams running self-hosted equivalents — aider, Cline against a local model, Continue — the local execution model is a genuine security advantage here, not a limitation. A jailbroken agent that can only write to your working directory and needs you to hit enter before it runs `curl` is dramatically less scary than one that can silently push to a fork.
Expect more of these. The prompt-injection surface area of a coding agent is enormous, and every new tool you wire in — a browser, a database client, a cloud console — adds another primitive. The interesting research question over the next year isn't whether agents can be jailbroken via untrusted content (they can, always), but whether anyone can build a permission model that survives contact with a hostile repo. Capability-based sandboxes, per-tool taint tracking, and human-approval gates for exfil-shaped actions are all plausible directions. Until one of them ships in a mainstream product, treat hosted coding agents as convenient, not safe.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.