Claude works inside an issue or pull request
Claude Code Action connects GitHub events to a coding agent with repository context. A maintainer can mention @claude, assign an issue, or run a workflow with an explicit prompt. The action decides whether the event calls for an interactive response or an automation job. It can explain code, review a diff, implement a bounded change, inspect Actions results when permitted, and update one progress comment as work proceeds.
Branch behavior is documented rather than left to prompt interpretation. An issue starts work on a new branch, an open pull request receives commits on its existing branch, and a closed pull request sends new work to another branch. The default flow does not open a pull request automatically after an issue task. It commits the change and returns a prefilled creation link, leaving the final PR creation step to a person.
The 506 MB install is the easy part
Our clean Debian sandbox cloned commit a874e9e with 3 CPUs, 8 GB of RAM, and no secrets. Bun installed 150 packages in 31 seconds, leaving 506 MB on disk. The repository had 222 files and roughly 32,563 source lines. There was no build script or target, so our harness skipped that step instead of inventing one. The checkout also contained 13 CI workflow files and a tests directory, but no Dockerfile.
A live deployment needs more decisions than that install. The quick path requires repository-admin access, installation of the Claude GitHub App, a workflow under .github/workflows, and an Anthropic credential stored in Actions secrets. Workload identity can replace a static Anthropic key with a short-lived token. Bedrock, Vertex AI, and Microsoft Foundry use their own OIDC setup and provider-specific model names. A custom GitHub App is available when organization policy or tighter permissions rules out the official app.
What happened when we ran it
Our bun test run finished in 38 seconds: 966 tests passed and 0 failed out of 966. Combined with the 31-second install, the supplied Node project completed every executable gate our harness found. There was no build result because the repository exposes no build target. That distinction matters for a packaged GitHub Action, since a green test command does not prove that a workflow has the right event filters, token permissions, or provider credentials.
The measured footprint is also worth keeping in a maintenance budget. Installing 150 packages expanded this 1.5 MB checkout to 506 MB. Those figures cover repository dependencies, not Actions minutes, model usage, or a real pull request. We did not provide secrets, call Claude, create a branch, or let the action write to GitHub. Production acceptance still needs a disposable repository where maintainers can inspect event behavior and the permissions attached to each generated token.
Write access makes the security guide required reading
The official GitHub App uses read and write access for contents, pull requests, and issues. By default, only repository users with write access can trigger the action, and bots are blocked. The danger begins when a workflow broadens those boundaries. The docs warn that allowed_bots: '*' on a public repository can permit an outside GitHub App to supply a prompt, even if that app is not installed on the repository. An explicit bot list is the safer configuration.
allowed_non_write_users is a sharper edge because it bypasses the primary actor check. Anthropic recommends a short-lived GITHUB_TOKEN, minimal workflow permissions, restricted tools, and output validation for that mode. The guide also says environment scrubbing and Linux process isolation reduce prompt-injection risk without eliminating it. Public projects that want every contributor to summon a write-capable agent should design a read-only or narrowly labeled workflow instead of granting general code access.
Pull-request files remain another trust boundary. For pull_request_target and workflow_run, the guide warns against placing an untrusted head checkout at the workspace root before the action. Selected Claude configuration files are restored from the base branch, while files such as package manifests, lockfiles, build scripts, and tool configuration can still come from the PR head. A trusted hook that invokes a package script may therefore execute contributor-controlled configuration.
One comment and no merge authority set the ceiling
The action cannot submit a formal PR review, approve a change, merge, or rebase. It communicates by updating a single initial comment. Those limits preserve human control, but they also rule out teams that need a conventional review object for branch protection or several threaded comments attached to separate lines. The action can prepare code and feedback; the repository's merge policy still needs people or other automation.
Current bug reports also deserve a pilot. Issue 1720 describes runs that returned a success subtype while doing zero turns or tool calls across several action versions. Issue 1747 reports a setup-branch failure path that exits before top-level cleanup and comment updates. These reports do not establish that every workflow is affected. They do justify alerting on empty output and failed progress updates rather than treating a green job status as sufficient proof of useful work.
August 2026 activity is high, and the queue is large
GitHub recorded a last push on August 28, 2026, 8,753 stars, and 724 combined open issues and pull requests. The recently updated queue included both fixes and user-reported failures, so the combined number should not be read as a bug total. The latest tagged release endpoint still pointed to v1.0 from August 26, 2025, while repository work continued in August 2026. The stale tag alone is not an abandonment signal.
Claude Code Action earns a trial for teams already comfortable with Claude and GitHub Actions. Our 966-of-966 result says the checked-out code passed its own available suite, while the security documentation gives operators unusually direct warnings about unsafe triggers and logs. Adoption should begin with one low-risk repository, minimal token scopes, no wildcard actors, and a workflow that cannot approve or merge what the model changes.