Can One GitHub Issue Hijack Claude Code, Gemini CLI, And Codex Workflows?
Researchers showed how one unprivileged GitHub issue could reach dangerous paths in Claude Code, Gemini CLI, and Codex workflows. Here is what was fixed.
Yes, under specific workflow conditions. Novee Security demonstrated that an unprivileged GitHub issue could reach dangerous execution or persistence paths in official Claude Code, Gemini CLI, and OpenAI Codex automations. Anthropic and Google published or referenced fixes for key vulnerabilities, while OpenAI hardened its own workflow. This was not a universal break of every local coding-agent session, and no exploitation in the wild has been established.
Watch The 30-Second Summary
The practical lesson is sharper than "prompt injection is bad." A low-trust issue became dangerous when an automated agent could read it, touch a runner or shared workspace, and hand state to a later step with credentials or write authority.
What Is Confirmed
Novee published its detailed Black Hat 2026 research on August 6. The researchers say they tested the vendors' own repositories and official agent workflows rather than hypothetical examples:
- Anthropic's Claude Code Action on the
anthropics/claude-coderepository; - Google's Gemini CLI workflow on
google-gemini/gemini-cli; and - OpenAI's Codex action in a two-pass issue-deduplication workflow on
openai/codex.
The three paths were not identical.
| Agent workflow | Reported boundary failure | Public confirmation or response |
|---|---|---|
| Claude Code | Command-validation mismatches, incomplete file-read checks, and a pre-approved web destination created successive execution and secret-exfiltration paths | Anthropic's GHSA-fg94-h982-f3mm confirms one reported exfiltration path and the fix in Claude Code 2.1.163; the reviewed GitHub Advisory Database record tracks it as CVE-2026-54316 |
| Gemini CLI | A nominal shell-command restriction was not enforced as expected, while a sanitized child process could still read secrets retained by its parent process | Google's GHSA-wpqr-6v78-jr5g rates the issue Critical at CVSS 10.0 and lists patched Gemini CLI and Action versions |
| Codex | One agent pass could write AGENTS.md into a shared workspace; a fresh second pass then loaded that file as instructions |
Novee says OpenAI separated the passes into different jobs within three days, then removed the checkout and hardened the workflow; OpenAI treated the underlying writable-workspace behavior as documented rather than assigning a CVE |
Google's advisory is unusually explicit. Gemini CLI before 0.39.1 and run-gemini-cli before 0.1.22 could automatically trust a headless workspace and mishandle fine-grained shell-tool restrictions under the documented conditions. The fix introduced a breaking trust change for headless execution.
Anthropic's public advisory confirms that a broad pre-approved Hugging Face hostname could be used as an out-of-band channel after untrusted content reached Claude Code's context. It lists affected Claude Code versions from 0.2.54 through 2.1.162 and a fix in 2.1.163. Standard auto-update users received the fix; manually maintained installations need to be checked.
Novee also says the vendors responded cooperatively and fixed the configurations it demonstrated. That matters: this is a disclosure about vulnerable trust handoffs and copied workflow designs, not evidence that the vendor repositories remain open to the same exact chains today.
What Is Still Unclear
Several important questions remain unanswered publicly:
- There is no verified count of private or public repositories that were actually exploitable at a particular time.
- Novee says it found similar configurations on more than 100 public repositories, but the report does not publish a complete affected-repository list.
- There is no public evidence that criminals exploited these chains before disclosure.
- The Claude Code research involved several rounds of patch and bypass. One public advisory confirms the final reported exfiltration path, but it is not a single bulletin covering every intermediate demonstration.
- The Codex finding did not receive a CVE. OpenAI's own workflow changed, but a separately authored multi-pass workflow may still reproduce the risky design if it shares a writable checkout.
- A workflow's real impact depends on its trigger, runner, token permissions, secrets, tools, network access, checkout layout, and what later steps do.
The absence of reported exploitation is not proof that no one was affected. It means the public evidence supports a vulnerable design and controlled demonstrations, not a measured breach campaign.
How Can One GitHub Issue Reach A CI Runner?
A GitHub issue is usually low-authority text. Anyone may be allowed to open one on a public repository. The issue becomes security-sensitive only when automation promotes it through a chain of trust.
The basic path looks like this:
- A stranger submits issue text that an AI agent will read.
- A workflow starts automatically or through a permissive mention rule.
- The model interprets the untrusted text alongside its legitimate task.
- The agent's harness grants file, shell, web, or reporting capabilities.
- The runner exposes a credential, writable checkout, public output, or later privileged stage.
- A generated action crosses the boundary the workflow designer expected to hold.
The model is only one component. The harness decides which tools exist, what files are writable, which domains are reachable, what approval is required, and which environment variables are visible. GitHub Actions decides the token permissions, secrets, event trigger, job boundaries, and persistence available to later steps.
This is why "the model was sandboxed" is not a complete answer. A sandbox can correctly restrict one process while a parent process, shared disk, report channel, or later job still exposes authority.
The Three Findings Were Not The Same Vulnerability
Claude Code: Safe-Looking Tools Became Data Paths
Novee describes three successive Claude Code paths. The first abused a mismatch between a command-validation layer and how a permitted program interpreted a flag. The second combined an incomplete list of path-checked read commands with a public workflow report. The third used a nominally read-only web request to an approved host as a measurable external signal.
The important pattern is not the specific payload. It is that separate components answered different questions:
- Is this command name approved?
- Does this utility count as read-only?
- Is this file path inside the workspace?
- Is this web hostname trusted?
- Can the workflow's report be viewed by the issue author?
Each individual rule sounded reasonable. The chain appeared when one layer's "safe" output became another layer's capability.
Anthropic's current Claude Code Action security guidance now emphasizes write-access gates, minimal workflow permissions, restricted tools, short-lived tokens, and the limits of best-effort prompt-injection defenses. Those controls reduce exposure, but they do not turn arbitrary issue content into trusted instructions.
Gemini CLI: Sanitizing A Child Was Not Process Isolation
Google's official advisory confirms two relevant changes for headless use. Older behavior automatically trusted workspace configuration in non-interactive environments, and a fine-grained tool allowlist could fail to constrain shell behavior under --yolo as expected.
Novee's deeper claim is that the workflow removed secrets from a spawned child's environment but left them in the parent process. If both processes shared the same user and process namespace, a child with shell access could read the parent's process metadata. The child looked clean when inspected directly, but the original secret-bearing process was still reachable.
Google now requires explicit workspace trust and enforces the corrected tool policy in the patched versions. Gemini CLI also documents optional sandboxing modes, but a workflow operator still has to choose and validate the right isolation for the actual runner.
Codex: A Shared Workspace Became Memory Between Agents
The Codex path is the most useful example because the sandbox reportedly behaved as designed.
OpenAI's issue-deduplication workflow ran Codex twice in one job using the same checkout. The first pass read an untrusted issue and could write normal workspace files. The second pass was fresh, but it loaded AGENTS.md from that shared disk as project instructions. Novee says the first pass could therefore leave instructions for the second one.
Output validation did not solve the problem. The malicious state moved through the filesystem rather than through the validated JSON output.
OpenAI's current Codex Action security guidance explicitly treats AGENTS.md, AGENTS.override.md, other project documents, PR text, commit messages, and screenshots as untrusted input surfaces. It also recommends running Codex as the last step in a job or passing its output to a fresh job when later steps need additional authority.
That distinction matters. The report does not show that every Codex session is remotely exploitable. It shows why two agent passes should not share a writable trust surface merely because a validator sits between their text outputs.
Use The CHAIN Audit Before Running An AI Agent In CI
OpenVeil's CHAIN audit turns the disclosure into a reusable review. Check all five links; a strong control at only one link is not enough.
| CHAIN link | Question to answer | Dangerous assumption |
|---|---|---|
| C — Content | Which issues, comments, PRs, commits, images, files, and instructions can reach the agent? | "The visible issue title is the whole prompt." |
| H — Hook | Who can trigger the workflow, and is a human approval gate real and specific? | "Opening an issue is harmless because it grants no repository permission." |
| A — Authority | What tokens, secrets, tools, network paths, package permissions, and repository scopes exist? | "A short-lived token cannot cause persistent damage." |
| I — Isolation | Are processes, users, filesystems, checkouts, reports, and network destinations actually separated? | "A sanitized child environment means the parent is unreachable." |
| N — Next stage | What reads files or output after the agent finishes, and does it carry more privilege? | "Validated JSON means the shared workspace is clean." |
The audit reveals why low-authority content can matter. The issue itself does not need credentials. It only needs a path to an automated component that already has them.
What Should Claude Code, Gemini CLI, And Codex Operators Do?
1. Update Before Debating The Model
For Gemini CLI workflows, confirm Gemini CLI 0.39.1 or newer and run-gemini-cli 0.1.22 or newer, then review the breaking headless-workspace trust behavior. Do not assume an unpinned latest reference proves every historical run was safe.
For Claude Code, confirm 2.1.163 or newer for CVE-2026-54316 and use the latest Claude Code Action. Review whether auto-update is actually enabled on every runner image, container, and cached installation.
For Codex, use the current Codex Action and security guidance. There is no single CVE version check for the shared-workspace pattern, so configuration review is essential.
2. Restrict Triggers At The Identity Boundary
Require write access or a deliberate maintainer approval before an agent processes outside content. Avoid wildcard users and bots. A label-based gate is useful only if the privileged actor reviews the raw input and the workflow cannot be retriggered or modified by the submitter afterward.
Do not rely on HTML rendering. Models may read comments, hidden markup, commit messages, image text, repository instructions, and fetched content that a maintainer did not inspect in the same form.
3. Split Low-Trust And High-Authority Work Into Different Jobs
Use a fresh runner and fresh checkout for the privileged stage. Pass only a narrow, validated artifact between jobs. Never carry forward a workspace that an untrusted agent could modify.
If a later step must use a token, make sure the earlier agent cannot write any file that later step will execute, import, source, parse as instructions, publish, or upload. That includes obvious paths such as workflows and hooks, plus less obvious files such as AGENTS.md, tool configuration, package manifests, build scripts, and generated artifacts.
4. Minimize The Token And The Blast Radius
Set GitHub workflow permissions explicitly. Prefer read-only repository access unless the task truly needs a write. Avoid package, deployment, organization, and cross-repository permissions in issue-triggered jobs.
Short-lived tokens still matter. A token can edit a workflow, publish a package, change a release, or create another persistent object before it expires.
GitHub's secure-use guidance for Actions recommends treating compromised runner state and untrusted input as first-class workflow risks. Token minimization is a containment control, not proof that prompt injection cannot occur.
5. Test The Handoffs With Harmless Canaries
Create a private test repository and harmless issue canaries. Verify that an untrusted actor cannot:
- start the workflow without the intended approval;
- cause a tool call outside the explicit allowlist;
- read a parent process's canary variable;
- write project instructions consumed by a later pass;
- place attacker-controlled text in a public report;
- make a later privileged job consume a modified workspace; or
- reach network destinations outside the documented policy.
Do not test exploit chains against public repositories you do not own. The goal is to prove your boundary, not reproduce another vendor's disclosure.
6. Review Historical Evidence
If a vulnerable workflow ran, preserve Actions logs, step summaries, artifacts, audit events, package publications, workflow edits, release activity, and token-use evidence. Look for unexpected issue-triggered runs and changes made after agent execution.
Rotate a credential when evidence says it may have been exposed. Do not rotate blindly and erase the only timeline showing what happened. Follow your incident-response process and preserve the original workflow revision first.
What This Does Not Prove
This disclosure does not prove that:
- every Claude Code, Gemini CLI, or Codex installation is vulnerable now;
- ordinary local terminal chat can be hijacked by any random GitHub issue;
- the underlying Claude, Gemini, or OpenAI model alone caused every failure;
- the vendors' current official repositories remain exploitable by the reported paths;
- a breach campaign used these findings in the wild;
- sandboxing is useless; or
- removing network access eliminates shared-disk, report, process, or later-stage risks.
It proves a narrower and more durable point: an agent's security is the product of the model, harness, workflow, runner, permissions, data flow, and every trust handoff between them.
Where OpenVeil Fits — And Where It Does Not
OpenVeil is a privacy-focused hosted AI workspace for adults who want chat, private web search, files, voice, image and video tools, custom personas, browser-local chat history, and no normal server-side chat-history record. It is not a GitHub CI coding agent and does not ask readers to grant an issue-triggered workflow repository tokens or package-publishing authority.
That narrower product shape can be a better fit when the job is private brainstorming, research, writing, file analysis, search, or media creation rather than autonomous repository automation. You can try OpenVeil's bounded preview without building and securing an agent runner.
The boundary is important: OpenVeil is not a sandbox, supply-chain defense, vulnerability scanner, or patch for Claude Code, Gemini CLI, Codex, or GitHub Actions. Active requests still must be processed by OpenVeil and necessary AI, search, upload, media, hosting, routing, security, billing, and infrastructure providers. OpenVeil does not make unrelated CI/CD risks disappear.
For related trust-boundary examples, see what happened when Anthropic and OpenAI agents created identities and touched public systems during UK testing, how a Word document carried self-propagating instructions into Microsoft Copilot, and why an AI sandbox failure reached Hugging Face production.
FAQ
Were Claude Code, Gemini CLI, And Codex All Affected By One CVE?
No. Novee grouped three different trust-handoff findings under one research theme. Google published a Critical advisory for Gemini CLI and its Action. Anthropic published a separate advisory and CVE for one Claude Code exfiltration path. The Codex shared-workspace finding was handled as a workflow and design hardening issue rather than one CVE covering all Codex use.
Can Anyone Open A GitHub Issue And Steal My Secrets?
Not automatically. The issue must reach an enabled workflow, the agent must receive enough capability, and a secret or privileged later stage must be accessible through the documented or another vulnerable path. Restrictive triggers, minimal permissions, separate jobs, clean checkouts, current versions, and tested isolation can break the chain.
Did The Sandboxes Fail?
That depends on the finding. Some paths involved enforcement flaws around tools or processes. In the Codex example, Novee says the workspace-write sandbox behaved as documented; the security failure was allowing a later agent to trust a file written by the earlier, untrusted pass.
Is Updating Enough?
Updating is necessary for the published Claude Code and Gemini fixes, but it is not sufficient for copied multi-stage workflows. Operators must also review triggers, token scopes, job separation, writable files, network paths, public reports, and every later consumer of agent-modified state.
Should AI Agents Never Run In CI?
No. The safer conclusion is that low-trust analysis and high-authority action need explicit separation. An agent can review or classify untrusted content on a restricted runner, then pass a narrow validated artifact to a fresh job. The second job should not inherit the first job's writable disk, processes, instructions, or broad secrets.
Bottom Line
Novee's Black Hat disclosure is credible evidence that one unprivileged GitHub issue could cross dangerous trust boundaries in specific official Claude Code, Gemini CLI, and Codex workflows. The vendors fixed or hardened the demonstrated configurations, and there is no public proof of exploitation in the wild.
The lasting question for every operator is not simply whether the model can be prompt-injected. It is whether untrusted content can cross the Content, Hook, Authority, Isolation, and Next-stage links of the CHAIN. If it can, the workflow has promoted a stranger's text into infrastructure authority.