One GitHub Issue Should Not Be Able to Steer Your Coding Agent
A Claude Code GitHub Action flaw showed how AI issue triage, broad repo permissions, and prompt injection can become a supply-chain problem.
The dangerous part was not that Claude misunderstood an issue.
That is almost boring now. Agents read text. Sometimes the text lies. Sometimes the model believes it.
The dangerous part was where the agent was sitting: inside GitHub Actions, holding repo permissions, reading attacker-controlled issues, and close enough to CI secrets that a prompt injection could turn into a supply-chain problem.
Security researcher RyotaK at GMO Flatt Security disclosed a flaw in Claude Code GitHub Actions that could let a malicious public GitHub issue reach workflows meant for trusted users. Anthropic fixed the issue in claude-code-action v1.0.94. The Hacker News covered the bug on June 4.
The short version: Claude Code's action had a permission check that trusted actors whose names ended in [bot]. That sounds reasonable until you remember that anyone can create a GitHub App, install it on a repo they control, then use that app to open an issue or pull request on a public repository. The target workflow sees a bot-shaped actor and may treat the input as trusted.
From there, the attack stops being clever in a magical way and starts being clever in a systems way. The issue body becomes the prompt. Claude reads it. The prompt tries to convince Claude to run commands. The command target is the workflow environment, where tokens and OIDC material live.
That is the bit everyone building agent workflows should sit with for a minute.
Agents inherit the blast radius you give them
Claude Code in GitHub Actions is useful because it can do real work. It can triage issues, label things, review pull requests, and run slash commands.
Real work needs permissions.
The default Claude GitHub App permissions described in the research are broad: code, issues, pull requests, discussions, and workflows. If an agent with that kind of reach processes hostile text, the question is not "can the model be tricked?" The question is "what can the model touch after it is tricked?"
That is why prompt injection keeps escaping the toy-demo box. A weird instruction hidden in an issue comment is not scary by itself. A weird instruction hidden in an issue comment, fed to an agent that can read secrets, write code, and alter workflows, is a different animal.
This is the same pattern behind a lot of recent AI-tooling incidents: the model is the weird interface, but the real failure is boring access control.
The bot shortcut was the bug, but the workflow shape is the lesson
RyotaK's write-up describes the bot bypass, the OIDC path, and a separate misconfiguration pattern involving allowed_non_write_users: "*". That setting lets non-write users trigger workflows, and Anthropic's docs already warn that it is risky.
The uncomfortable part is that example workflows get copied. A safe-looking demo becomes production glue. Someone adds a secret because the agent needs to call another API. Someone grants another permission because the agent needs to edit labels or touch files. Six months later, a random issue is not just a random issue anymore. It is input to automation with hands.
This is not an argument against AI coding agents. I use these tools. They are useful.
It is an argument against treating them like chat widgets once they enter CI.
A GitHub Actions agent is closer to a junior automation account with a strange natural-language parser than it is to a helpful sidebar. You would not give a junior contractor repo write access, workflow write access, secrets, and instructions from anonymous issue comments without guardrails. The same standard should apply here.
What to check if you use Claude Code in GitHub Actions
First, update anthropics/claude-code-action to v1.0.94 or later.
Then do the less glamorous work:
- Audit every workflow that can be triggered by issues, pull requests, comments, or slash commands.
- Remove
allowed_non_write_users: "*"unless you have a very specific reason and a tight permission boundary. - Do not expose extra secrets to workflows that process public text.
- Pin permissions explicitly in the workflow instead of accepting broad defaults.
- Treat
GITHUB_TOKEN, OIDC credentials, npm tokens, cloud tokens, and deployment keys as toxic waste around agent-readable input. - Check workflow run logs and summaries for suspicious output, especially if the agent ever summarized environment data or command output.
- Make the agent's output channel boring. Public issue comments and workflow summaries are easy exfiltration paths.
The practical rule is simple: if untrusted people can write text the agent will read, the agent should not have access to anything you would panic about seeing pasted back into that thread.
This keeps rhyming
The same week had other stories in the same family. Fake open-source tool sites ranked in search and pushed malware through a Traffic Distribution System. OAuth marketplace apps kept broad access after publishers vanished. Agentic SAST tools are getting better at finding bugs, but they also need code access, model access, and sometimes secrets.
None of these are identical. They rhyme because developer trust keeps getting converted into execution.
Search result trust becomes a download. Marketplace trust becomes an OAuth grant. Issue-triage trust becomes an agent with repo permissions. The attacker does not need to break the whole platform if they can find the place where trust quietly turns into action.
AI agents make that conversion faster and more confusing. They can read a messy issue, decide what matters, run commands, and explain afterward in a tone that sounds confident enough to skim past.
That is useful. It is also exactly why the boundary has to be tighter than "the model will probably know better."
It will not always know better.