What happened
Depi Security’s November 11, 2026 write-up describes a vulnerability in the issue-labeling workflow for the openai/codex GitHub repository. The workflow used openai/codex-action version 1.7 and ran when an issue was opened or when an issue received the codex-label label. Its prompt incorporated an issue’s title and body, fields that an external user could control. The action configuration included allow-users: "*"; according to Depi, that meant the workflow was not restricted to trusted maintainers.
Depi says its researchers found a prompt pattern that made Codex treat attacker-controlled issue text as instructions rather than as data. Their account says this injection led to arbitrary shell-command execution inside the agent sandbox. The post describes the sandbox as running in workspace-write mode, with filesystem restrictions, disabled network-related syscalls, disabled process debugging, and no sudo privileges. That containment limited the initial command execution, but it did not end the chain.
The researchers say they found .NET CoreCLR debug pipes in /tmp/ on the GitHub runner. Although the sandbox prevented connection to a diagnostic socket, Depi says the pipes could be opened as files. Its technical account describes an unauthenticated debug-session handshake and use of a CoreCLR memory-read operation against the runner process. Depi says job-scoped values, including runtime and GitHub tokens, remained in the memory of runner processes even though the sandboxed environment itself did not expose them.
Depi then describes using the obtained access in a sequence involving GitHub Actions cache read and write access. A later workflow could restore a poisoned cache, creating what the researchers characterize as a release booby trap. The chain ultimately reached OpenID-based trusted publishing for OpenAI’s official @openai/codex package on npm. Depi describes that package as downloaded millions of times per month and frames the result as a route to influence a future release, rather than a claim that a compromised package was published.
Depi says it reported the issue to OpenAI through Bugcrowd, that OpenAI fixed the core issue, and that no malicious release reached users. The finding is therefore a disclosed and remediated exploit path, not evidence of a completed supply-chain compromise. It nevertheless connects a public repository input, an agent capable of running commands, runner-level state, a shared cache, and release publishing in one chain.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This supports Agent security moves to runtime boundaries. The problem was not merely hostile wording reaching a model: Depi’s chain depended on what the agent could execute, what it could reach through the runner, and how later workflows reused state. Prompt guardrails could not serve as the final enforcement boundary.
Why now
Coding agents are increasingly placed inside repository automation, where issue and pull-request text may be public and adversarial while adjacent jobs hold tokens, caches, or publishing authority. Depi’s account shows how these layers can compose: a workflow intended to triage issues became a potential path through runner processes and toward package release machinery.
Why it matters
The lesson for an AI engineering team is architectural. A workflow that asks an agent to inspect public issues or pull requests should be designed as an untrusted workload, even if its immediate task is harmless labeling or review. The dangerous combination is untrusted natural-language input plus execution capability plus access—direct or indirect—to secrets, persistent caches, or downstream release jobs.
Separate those roles. Give public-input agent jobs narrowly scoped, read-only permissions where possible. Do not place publishing credentials in their environment. Do not let caches, artifacts, or tokens become an unreviewed bridge from an untrusted job into a privileged release path. Test the runner and workflow boundary under the assumption that an agent can be manipulated into executing an unexpected command. The practical control is not a better instruction to the model; it is reducing the authority available after that instruction fails.
What happens next
- AI-agent GitHub workflows will receive more scrutiny around public issue and pull-request triggers. (3 months, 70%). Watch for: permission reductions, maintainer-only gates, or separate untrusted runners.
- Teams will split agent analysis from package-release credentials and cache paths. (6 months, 65%). Watch for: isolated workflows and explicit artifact promotion steps.
Limits and uncertainty
The exploit chain and its technical details are Depi Security’s account; this note does not independently reproduce the attack or verify the remediation. Depi says OpenAI fixed the core issue and that no malicious release reached users, but the exact scope and durability of the remediation are not independently established here. The account demonstrates a route toward package publishing, not a completed compromise of the npm package. It also does not measure how commonly comparable combinations of public input, agent execution, runner access, and shared caches exist across other repositories.
Skill to build now
This week, map every CI workflow that sends issue or pull-request text to an agent. For each one, list its token permissions, accessible secrets, writable caches, artifacts, and any downstream workflow that consumes its output. Then remove release authority from that path and require a separate, privileged promotion step. Treat cache keys and artifact handoffs as security boundaries, not only build-speed optimizations.
Reader takeaway
An AI agent that reads public repository text should not share a CI job’s secrets, privileged tokens, or release cache. Keep untrusted analysis separate from publishing authority, and enforce that separation through workflow permissions, execution isolation, and controlled handoffs rather than prompt instructions.