Claude Code Action 1.0.139 Keeps CI Agents Current While the Security Story Gets Loud

The changelog for claude-code-action v1.0.139 is almost aggressively boring: bump Claude Code to 2.1.167 and Agent SDK to 0.3.167. That is exactly why teams should pay attention.

Claude Code Action is not a decorative wrapper around a chatbot. It is a GitHub Actions participant that can read repository state, interpret issue and pull-request text, use tools, write comments, create changes, and run inside the same CI environment that often carries tokens and secrets. When Anthropic ships an action bump within an hour of runtime changes — v1.0.138 picked up Claude Code 2.1.166 and v1.0.139 picked up 2.1.167 — the release is part of the supply-chain story, not just dependency hygiene.

The timing is hard to ignore. Microsoft Threat Intelligence published a detailed case study on June 5 showing how Claude Code GitHub Action could expose CI/CD secrets when an AI agent processed untrusted GitHub content. GMO Flatt Security had already documented related attack paths around prompt injection, GitHub App trust assumptions, permissive workflow settings, and CI credentials. Anthropic has fixed the specific issues discussed in those disclosures, including an earlier mitigation in Claude Code 2.1.128 and Claude Code Action fixes around v1.0.94. But today’s release is the maintenance half of that security arc: if you let an agent run in CI, staying current is not optional housekeeping.

The dependency bump changes the runtime inside your workflow

The v1.0.139 release landed on June 6 at 01:35:37 UTC. The previous v1.0.138 release landed at 00:57:10 UTC. The compare from v1.0.137 to v1.0.139 showed two commits and six changed files: base-action/action.yml, lockfiles, package manifests, and src/entrypoints/run.ts. Commit 41016583 bumped Claude Code to 2.1.166 and Agent SDK to 0.3.166. Commit 64de7440 bumped Claude Code to 2.1.167 and Agent SDK to 0.3.167.

That sounds mechanical, but the embedded runtime is where the important behavior lives. Claude Code 2.1.166 added fallback model routing, deny-rule glob support, hardened cross-session SendMessage authority handling, explicit thinking-disable controls, managed-settings enforcement fixes, and a set of background-agent and remote-session reliability repairs. In a local terminal, those are developer-experience improvements. In CI, they are controls over how untrusted prose, tool permissions, model routing, policy files, and workflow state interact.

This is the mistake teams make with AI actions: they treat the action version like a normal package version. It is closer to a mini agent platform running inside GitHub Actions. A bump can change which tools are available, how permission rules are interpreted, whether policy config fails open or closed, how model failures recover, and how sessions coordinate. That does not mean every release is dangerous. It means every release is operationally meaningful.

The security lesson is not “Claude bad”; it is “CI is hostile input”

Microsoft’s case study focused on a boundary mismatch. In risky GitHub Action contexts, Bash subprocesses used Bubblewrap sandboxing with environment scrubbing through CLAUDE_CODE_SUBPROCESS_ENV_SCRUB. But the Read tool was an in-process path, not subject to the same isolation boundary. Microsoft showed the Read tool accessing /proc/self/environ, where the process environment contained ANTHROPIC_API_KEY. Anthropic mitigated the issue in Claude Code 2.1.128 by blocking sensitive /proc files.

The bug is instructive because it is not exotic. The system had a mitigation for one capability path and a gap in another. Attackers do not care whether the safe path was Bash and the unsafe path was Read. They care that the agent can be steered toward whichever capability exposes the value. Security policy has to apply by capability and data class, not by the implementation detail that happens to execute the tool.

The other half of the problem is prompt injection. GitHub issues, pull-request descriptions, comments, labels, and files from forks are not just collaboration surfaces when an AI workflow consumes them. They are inputs to a tool-using process. Microsoft described prompt injection hidden inside HTML comments: invisible in the rendered browser view, visible in raw Markdown consumed by the model. That gap between human-visible context and model-visible context is exactly where agent attacks will keep living.

Flatt’s earlier work points in the same direction. The risky pattern is not a single vulnerable version; it is the combination of permissive settings, broad GitHub token permissions, bot-authored events, untrusted issue text, and an agent that can act on the repo. Settings like allowed_non_write_users: "*" may look convenient for public issue triage. They also let strangers write part of the prompt for a CI participant.

What teams should do before the next disclosure

The practical response starts with updating. If you use anthropics/claude-code-action@v1, verify what version the moving tag resolves to and whether your change-management process is comfortable with that. If you pin exact tags, move to v1.0.139 or newer and establish a release-update path that can react faster than a security blog cycle. Pinning without maintenance is just fossilized risk.

Then audit the workflow like an attacker would. What untrusted text can reach the agent? Include issues, PR bodies, comments, file diffs, labels, MCP responses, web fetches, and any content from forks. What can the agent read? Include repository files, environment variables, generated artifacts, workflow logs, GitHub API responses, and local runner paths. What can it write? Comments, summaries, labels, PR branches, code, release notes, package manifests, and external network requests all count. Finally: if prompt injection succeeds, where can the data leave? Logs, issue comments, workflow summaries, WebFetch, Bash, MCP tools, and PR bodies are all exfiltration channels.

The minimum baseline is blunt: scope GITHUB_TOKEN to read-only unless write is essential; avoid secrets in workflows triggered by non-writers; restrict allowedTools; separate triage from code-writing jobs; keep public summaries disabled for sensitive runs; review prior logs for leaked environment data; and treat MCP servers as part of the action’s attack surface. If the workflow needs secrets, it should not be triggerable by strangers. If it is triggerable by strangers, it should not see secrets.

The reason v1.0.139 matters is not that its release note is dramatic. It is that AI CI actions inherit all the old GitHub Actions risks and add a model that treats natural language as potential instruction. A boring bump to the underlying runtime can bring the policy, permission, and sandboxing fixes that keep the system inside the lines.

The editorial take: Claude Code Action releases should be tracked like CI infrastructure, because that is what they are. The action is not merely running Claude. It is deciding how untrusted prose interacts with your repository, tokens, tools, logs, and release process. That deserves the same seriousness as any other supply-chain component.

Sources: Anthropic Claude Code Action v1.0.139 release, Claude Code Action v1.0.138 release, Claude Code v2.1.166 release, Microsoft Threat Intelligence, GMO Flatt Security