Agent chaosVerified·14 Nov 2026
One GitHub issue could hijack OpenAI's Codex labeling bot and open a path to the official npm package
Security researchers showed one crafted GitHub issue could prompt-inject the Codex bot that labels issues in OpenAI's own repo, escape its sandbox and reach the pipeline that publishes the official Codex npm package. OpenAI fixed it; no bad release shipped.
OpenAI's Codex repo had a little helper: an AI agent that read every new GitHub issue and suggested labels. Security researchers found that anyone who could open an issue could also give that agent orders, and they followed the thread all the way to the release pipeline for one of the most downloaded AI coding tools around.
What happened
On 11 November a two-person team at a small security firm published a full exploit chain against the openai/codex repository on GitHub. The target was an issue-labeling workflow that ran OpenAI's own Codex agent through a GitHub Action. It fired whenever a new issue was opened, it accepted issues from any user, and it pasted the issue's title and body straight into the agent's prompt.
So the researchers wrote an issue that didn't read like a bug report to the model. It read like more instructions. The agent followed them and ran the researchers' commands inside its sandbox, and the issue also told it to keep the job alive, because the tokens they were after only worked while the workflow was still running.
How it went wrong
The sandbox only let the agent write to its working folder and /tmp. That turned out to be the gap. The GitHub runner processes, built on .NET, left debug pipes in /tmp, and the team used them to read the runner's memory and pull out its environment, including the GitHub token and the token used for the Actions cache.
With those tokens, the researchers say, they could slip a poisoned entry into the repository's Actions cache. The cache key could be worked out without any secrets, and cache contents weren't checked before being unpacked. A later, more privileged CI workflow restored that cache and ran a planted test file. From there they describe getting write access and a way to mint the signed identity token that npm's trusted publishing accepts, which is the key to pushing a new version of the official @openai/codex package.
That package gets millions of downloads a month. And a poisoned coding agent doesn't need a clever way to run on a developer's machine. Running code is its whole job.
What OpenAI did
The team reported the chain through OpenAI's bug bounty program. They say OpenAI deployed a fix right away and paid an initial $1,000 bounty while the report stayed under review. Nobody has reported a malicious Codex release reaching users, and the researchers stopped short of publishing one.
Our take
This is a research finding, not a breach, but the pattern is everywhere. An AI agent that reads text strangers wrote, inside a job that holds write tokens, shared caches or publishing rights, is one prompt away from becoming the attacker's employee. Labeling an issue needs read access and nothing else. Give it exactly that, keep untrusted jobs away from release caches and secrets, and put a human between CI and any publish step.
An agent that reads strangers' text should never hold write tokens, shared caches or publish rights.

