`cpSync` defaults to `dereference: false`, which means it tries to
recreate symlinks at the destination rather than copying file contents.
When a sensitive path (e.g. CLAUDE.md) is a symlink, this fails with
`ENOENT: no such file or directory, symlink` because `cpSync` attempts
to call `symlink()` without ensuring the parent `.claude-pr/` directory
exists first.
Adding `dereference: true` fixes this by following symlinks and copying
the actual file contents, which is also the correct semantic behavior —
review agents need to inspect the real content, not a symlink that may
not resolve correctly from `.claude-pr/`.
Fixes the action crash when repositories use symlinked CLAUDE.md
(e.g. CLAUDE.md -> AGENTS.md).
`validateBranchName` rejects branch names containing a comma, even
though `git check-ref-format` permits commas and GitHub itself accepts
them. PRs whose head branch contains a `,` fail validation in-process
before any git operation, so the action errors out immediately.
Branch names with commas show up in real workflows when names are
derived from titles, place names, or external identifiers (e.g.
"feature/paris,france"). There is no workaround other than renaming
the branch, which is often not under the user's control.
All git calls in this file use execFileSync with an argv array, so no
shell interpretation occurs and `,` carries no injection risk. This is
the same reasoning used to add `#` in #1167 and `+` in #1248.
- Add `,` to the validateBranchName whitelist regex
- Update the surrounding comment and error message to match
- Add a test case covering commas in title-derived branch names
Fixes#1300
GitHub @-mention autocomplete inserts @Claude (capitalized) when users
pick the bot from the dropdown, but the trigger regex had no 'i' flag,
so the action would log 'No trigger was met for @claude' and exit. The
workflow's outer 'if: contains(...)' gate is case-insensitive, so the
job runs and looks like it silently ignored the user.
The regex was case-sensitive since the initial commit with no test
asserting either behavior; the existing tests focus on word-boundary
precision (email@claude.com etc.), not case.
Claude Code's EnterWorktree tool converts "/" to "+" when generating
branch names from worktree names (e.g. EnterWorktree("feat/foo") creates
branch "worktree-feat+foo"). The strict whitelist in validateBranchName
rejected these names, causing claude-code-action to fail on any PR opened
from an EnterWorktree-generated branch.
Since all git calls use execFileSync (not shell interpolation), "+" carries
no command injection risk — the same rationale used for allowing "#".
Git itself permits "+" in branch names per git-check-ref-format.
Fixes: https://github.com/anthropics/claude-code-action/issues/1244
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Agent SDK 0.2.113 dropped vendor/ripgrep and now ships native binaries
via per-platform optionalDependencies. Two breakages:
- action.yml chmod'd vendor/ripgrep which no longer exists, failing the
Install Dependencies step with find exit 1.
- The SDK auto-resolves its bundled binary by trying the -musl platform
package before the glibc one. bun install does not respect the
package.json libc field and installs both on glibc Linux, so the SDK
picks the musl binary and spawn fails with ENOENT.
Remove the obsolete ripgrep chmod. Make installClaudeCode() return the
install.sh binary path and pass it explicitly as
pathToClaudeCodeExecutable so the SDK skips auto-resolution entirely.
When a PR originates from a fork, `git fetch origin <branch>` fails
because the branch only exists on the fork's remote.
Fix: detect cross-repository PRs via the `isCrossRepository` GraphQL
field and fetch using `pull/<number>/head:<branch>` refspec instead,
which is the standard GitHub mechanism for accessing fork PR branches.
Changes:
- Add `isCrossRepository` and `headRepository` to PR GraphQL query
- Add corresponding fields to GitHubPullRequest type
- Branch checkout uses pull ref for fork PRs
- Update test fixtures with new fields
Co-authored-by: User <user@example.com>
dirname() preserves embedded newlines, so a value like
`/usr/bin/claude\n/attacker/path` writes two lines to GITHUB_PATH,
injecting an attacker-controlled directory into PATH for all subsequent
workflow steps.
Validate the input immediately after reading it and throw if it
contains any control characters (0x00-0x1f, 0x7f). This is fail-closed
rather than silent stripping — a path with control characters is always
misconfigured or malicious.
Fixes#1160
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
When a PR modifies files under .claude/, the security restore in
restoreConfigFromBase() overwrites them with the base branch version —
correct for execution safety, but it means review agents never see what
the PR actually changes.
Before deleting the PR-controlled .claude/ tree, copy it to .claude-pr/.
Review agents can read .claude-pr/ to inspect the PR's hooks, MCP
configs, settings, and CLAUDE.md without those files ever being executed.
The snapshot is taken before the security delete so it captures the full
PR-authored version.
Fixes#1134.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
When a PR head contains `.gitmodules`, git's default
`fetch.recurseSubmodules=on-demand` config causes `git fetch` to attempt
submodule object fetches. In CI (no credentials), this blocks indefinitely
waiting for auth — producing ~4-hour hangs reported in #1088.
Two changes, both defence-in-depth:
1. Delete SENSITIVE_PATHS *before* fetching. The attacker-controlled
`.gitmodules` is absent during the network operation, so git never
sees a submodule config to follow regardless of git settings.
2. Pass `--no-recurse-submodules` to the fetch. Suppresses submodule
fetching explicitly, independent of any git config on the runner.
The original order (fetch-then-delete) was a brief window where
`.gitmodules` from the PR head could influence the fetch. Reordering
also tightens the security property: if `git checkout` below fails, the
attacker-controlled file is already gone rather than present during fetch.
Fixes#1088.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
`validateBranchName` used a strict whitelist that excluded `#`,
causing the action to fail on PRs from branches like `put-back-arm64-#2`
with "Invalid branch name" — even though the branch already exists in
git and `#` is permitted by git-check-ref-format.
The validation was designed to prevent command injection. However, every
git call in the action uses `execFileSync`, which bypasses the shell
entirely and passes arguments directly to the kernel's execve. There is
no shell to interpret `#` as a metacharacter, so the strict whitelist was
over-blocking valid names with no security benefit.
Add `#` to the whitelist pattern, and update the JSDoc and error message
to reflect the allowed character set.
Fixes#1137.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
