Claude Code Action 1.0.137 Keeps CI on the Latest Agent Runtime After a Week of Supply-Chain Warnings

Claude Code Action 1.0.137 is the kind of release note that looks forgettable until you remember where it runs. Anthropic’s GitHub Action shipped today with a narrow change: bump Claude Code to 2.1.165 and the Agent SDK to 0.3.165. In a normal dependency graph, that is housekeeping. In a CI workflow that can read issues, inspect pull requests, run tools, touch repository state, and summarize its own work back into GitHub, housekeeping is part of the security boundary.

That is the right lens for this release. The interesting story is not that a package version changed. It is that Claude Code in GitHub Actions is now a privileged automation component, and privileged automation components need boring operational discipline: current versions, explicit trigger rules, least-privilege tokens, reviewable logs, and a healthy distrust of user-controlled prose.

The release itself is compact. Anthropic published claude-code-action v1.0.137 on June 5, 2026 at 05:46:55 UTC. The compare from v1.0.136 to v1.0.137 shows a single commit, 41ea7642, changing six files: base-action/action.yml, two package manifests, two lockfiles, and src/entrypoints/run.ts. The commit message says the quiet part plainly: “bump Claude Code to 2.1.165 and Agent SDK to 0.3.165.”

That would be unremarkable if this action were formatting Markdown. It is not. Claude Code Action sits inside GitHub Actions, where the difference between “helpful assistant” and “supply-chain participant” is mostly a YAML file and a token scope.

The action is small; the blast radius is not

The timing matters because the Claude Code Action ecosystem spent the week absorbing a much louder security lesson. RyotaK at GMO Flatt Security disclosed a set of issues in Claude Code GitHub Action workflows that combined GitHub App trust assumptions, permissive workflow settings, indirect prompt injection, and CI credentials into a repo-compromise path. Anthropic fixed the core issue earlier in v1.0.94, and today’s v1.0.137 is not presented as that fix. But it is the current moving baseline after the disclosure, and teams should treat it that way.

The disclosed pattern is worth spelling out because it is exactly where AI CI integrations get dangerous. Agent mode allowed actors ending in [bot] to pass a permission check, while GitHub Apps can create issues or pull requests on public repositories without being installed on the target repository. That creates a nasty trust mismatch: a workflow thinks it is responding to a trusted automated actor, while an attacker has found a path to inject text into the agent’s context.

Once that happens, the model is not merely “reading a comment.” It is interpreting untrusted text inside an environment that may have repository permissions, workflow visibility, issue write access, pull request context, and sometimes secrets. Prompt injection stops being a parlor trick when the prompt sits next to a GITHUB_TOKEN.

Flatt’s report also called out the tempting configuration shortcut allowed_non_write_users: "*". That setting is understandable: maintainers want community issue triage to work without babysitting every contributor. It is also the exact kind of convenience knob that turns a public issue tracker into an internet-facing agent endpoint. If the workflow can see sensitive context or write output anywhere public, a non-writer trigger is not harmless. It is an input channel.

Prompt injection in CI is just CI security with worse ergonomics

The uncomfortable part for engineering teams is that none of this is conceptually new. GitHub Actions has had sharp edges for years: pull_request_target footguns, overbroad tokens, secrets exposed to untrusted builds, shell scripts that trust branch content, workflows that run because someone copied a blog post. AI agents do not invent the supply-chain problem. They make it fuzzier.

Traditional CI security at least gives you fairly crisp artifacts: YAML triggers, shell commands, token permissions, dependency versions. With an AI agent, the control plane includes natural language. Issue titles, PR descriptions, review comments, MCP tool output, fetched web pages, and generated summaries can all become instructions unless the harness and workflow design make that impossible or irrelevant. The model is probabilistic, but the permissions are real.

That is why today’s dependency bump matters more than its changelog suggests. The embedded Claude Code runtime is not just a library. It is the component deciding how tools are invoked, how permissions are interpreted, how model output becomes action, and how the workflow handles edge cases. If your organization pins exact action versions, you need an explicit update process. If you use a moving tag such as @v1, you need monitoring that tells you what actually ran. “We are on v1” is not an inventory answer. It is a shrug with semantic versioning.

The adjacent Claude Code release, 2.1.165, is itself terse, but it follows the more substantive 2.1.163 line that added managed minimum and maximum version gates, plugin inventory, richer hook feedback, MCP session continuity, and fixes around permissions and background tasks. That direction is the real signal: Anthropic is slowly adding the primitives teams need to run agent tooling as managed infrastructure instead of developer-local magic.

What teams should change before the next clever issue title

The practical checklist is not glamorous, which is usually how you know it is useful.

First, update Claude Code Action to v1.0.137, or at minimum verify every workflow is past v1.0.94, the version Flatt says contains Anthropic’s fix for the disclosed vulnerabilities. Do not assume a tag in a README reflects what your workflows actually execute. Check workflow history, resolved action SHAs, and dependency automation.

Second, remove allowed_non_write_users: "*" unless the workflow has been threat-modeled as a public endpoint. If non-writers can trigger the agent, design as if adversarial users can control every byte of the prompt. That means no secrets, no write tokens unless absolutely required, no access to private project context, and no public summaries containing sensitive intermediate state.

Third, separate issue triage from code-changing automation. A workflow that labels issues, drafts summaries, or routes bug reports should not be the same workflow that edits files, pushes branches, comments with internal reasoning, or opens privileged PRs. Humans separate read paths and write paths in production systems for a reason. Agents do not get an exemption because they are polite in Markdown.

Fourth, reduce token scope. Prefer read-only GITHUB_TOKEN permissions where possible, explicitly set permissions in workflow YAML, and avoid repository-wide defaults. If a workflow only needs issues read/write, do not give it contents write. If it only needs PR comments, do not give it workflow permissions. Least privilege is boring until the model follows an attacker’s instructions perfectly.

Fifth, treat logs and summaries as data-loss surfaces. AI actions often write helpful explanations into job summaries, comments, or artifacts. That is useful for debugging, but it also creates a place for secrets, private paths, internal repo details, or prompt-injected output to leak. Review what the action emits, not just what it changes.

Finally, write down ownership. Someone should be able to answer: which Claude Code Action versions are allowed, which workflows can be triggered by outsiders, which token scopes are approved, what tools Claude may use, where outputs are published, and how a suspicious run is revoked or audited. If the answer is “the AI platform person knows,” you do not have a control plane. You have a person-shaped cache.

The bigger lesson is that AI agents in CI collapse two environments that used to be easier to keep apart: public collaboration surfaces and privileged automation. That collapse is the product. It is why maintainers want Claude in issues and pull requests in the first place. But if the agent can act on untrusted prose, the workflow has to be designed like an exposed service, not like a clever bot command.

Claude Code Action 1.0.137 will not be remembered as a dramatic release. It probably should not be. But it is a useful reminder that in agent infrastructure, staying current is not cosmetic. The boring dependency bump is the patch lane, the policy lane, and sometimes the only thing standing between “Claude summarized an issue” and “Claude helped an attacker operate your CI.”

Sources: Anthropic Claude Code Action v1.0.137 release, GMO Flatt Security disclosure, The Hacker News recap, Claude Code v2.1.165 release