GitHub's GraphQL author field is null when the account behind a
comment, review, PR, or issue has been deleted (the ghost user). The
action typed author as non-null and read author.login directly, so a
single comment from a deleted account threw and was swallowed into a
generic 'Failed to fetch PR/issue data', failing the entire run.
Make author nullable on the four affected types and fall back to
'ghost' at each login read. With the type nullable, tsc flags every
dereference, so all sites are covered.
Branch names starting with an underscore (e.g. _release/v1.2.3) are valid
per git check-ref-format but were rejected by validateBranchName's
first-character whitelist. Since setupBranch validates a PR's baseRefName
after checkout, the action failed on every open PR targeting such a
branch. A leading underscore carries no option-injection risk (only a
leading dash does, which is still rejected separately).
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
stripMarkdownImageAltText removed alt text from inline images
() but not reference-style images (![alt][ref]), because the
regex requires the "](" of the inline form. Alt text is a
hidden-instruction channel that reaches the prompt via sanitizeContent,
so the reference-style form let it survive.
Add a matching replace for the reference-style form (![alt][ref] ->
![][ref]), preserving the [ref] label so the image definition still
resolves. Adds regression tests.
Co-authored-by: Contributor <you@example.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A scoped label like area:permissions was substituted into the branch
name verbatim, producing a ":" that validateBranchName rejects. Because
the branch setup block catches that error and calls process.exit(1), the
whole run died. {{description}} was already sanitized via extractDescription;
{{label}} was the only free-text variable that skipped it.
Add a sanitizeLabel helper (replaces invalid-char runs with a hyphen so
scoped labels stay readable) and apply it before substitution, falling back
to entityType when a label sanitizes to empty. Adds regression tests that
also assert the result passes validateBranchName.
* test: cover prepareContext validation error branches
create-prompt.test.ts exercised only happy paths; the ~20 validation
guards in prepareContext (missing PR_NUMBER, unsupported event type,
unsupported issue action, missing claude branch, etc.) had no coverage.
Adds a "prepareContext validation errors" block asserting the thrown
messages for the reachable guards, using the existing createMockContext
helper.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* test: cover comments/common link and body builders
`src/github/operations/comments/common.ts` had no direct test coverage,
though its exports are live code used by create-initial.ts and
update-with-branch.ts. This adds unit tests for all four exports:
SPINNER_HTML, createJobRunLink, createBranchLink, and createCommentBody.
Assertions are built from the imported GITHUB_SERVER_URL so they hold on
GHES as well as github.com. Pure test additions — no production changes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
redactGitHubTokens covers ghp_, gho_, ghs_, ghr_, and github_pat_
tokens but misses ghu_ (GitHub App user-to-server tokens), one of the
documented GitHub token prefixes. A ghu_ token appearing in issue or
PR content passed through sanitization unredacted.
Add the ghu_ pattern, mirroring the existing 40-character token
patterns, with unit tests including the git-credential URL form.
installClaudeCode() pipes `curl -fsSL | bash -s --`. Bash exits with
the status of the last command, so when curl fails (429 rate limit,
403, or connection error) `bash -s` still exits 0 on empty stdin and
the action logs "Claude Code installed successfully". The 3-attempt
retry loop never triggers because the first attempt looks successful,
and the run later dies with "Executable not found in $PATH: claude".
Prefix the pipeline with `set -o pipefail;` so curl's non-zero exit
propagates through the pipe and the retry loop can actually kick in.
Extracted into buildInstallCommand() with regression tests covering
both the old buggy shape and the fixed one.
When snapshotting PR-authored sensitive paths into .claude-pr/, cpSync with
dereference:true throws ENOENT if a symlink target is missing on the PR head
(e.g. .claude/CLAUDE.md -> ../AGENTS.md). Fall back to copying the symlink
itself so restoreConfigFromBase can continue and restore trusted base versions.
Fixes#1398
When classify_inline_comments is enabled, create_inline_comment buffers calls
without confirmed=true. The model frequently re-issues the call with confirmed=true
after reading the buffered reply, which posts the comment live but leaves the
original buffered entry behind. The post-session replay step then posts it again,
so every inline comment lands twice.
Reconcile the buffer on a live post: after a confirmed comment is created, remove
any buffered entry matching the same path, line, startLine and body so it cannot be
replayed. Extracts the reconciliation into src/mcp/inline-comment-buffer.ts (the MCP
server module starts a server on import) and adds unit tests.
Co-authored-by: archievi <13202986+archievi@users.noreply.github.com>
`validateBranchName` rejects branch names containing `@`, even though
`git check-ref-format` permits `@` and GitHub itself accepts such
branches. PRs whose head or base branch contains an `@` fail validation
in-process before any git operation, so the action errors out
immediately.
Branch names with `@` show up in real workflows: ticket conventions
like "TICKET-123@add-feature" (#998), leading-prefix conventions like
"@hotfix/...", and agent tooling that appends "@<sessionid>" (#1305).
There is no workaround other than renaming the branch, which is often
not under the user's control.
Branch names are never passed through a shell (git calls use
execFileSync argv arrays), so `@` carries no injection risk. This is
the same reasoning used to add `#` in #1167, `+` in #1248, and `,` in
#1310. The bare name "@" (HEAD shorthand in git revision syntax) and
the "@{" reflog sequence are still rejected.
- Add `@` to the validateBranchName whitelist regex, including the
leading position (the leading-character rule blocks option injection
via `-`, which `@` cannot cause)
- Reject the bare name "@" with a dedicated check
- Update the surrounding comment, JSDoc, and error message to match
- Add test cases for @-containing names and bare "@"
Fixes#998
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Adds unit tests for previously-uncovered branches in
src/entrypoints/format-turns.ts:
- detectContentType: malformed-JSON fall-through (objects and arrays)
and the default python classification for non-python/non-js code
- formatResultContent: non-string inputs (number, plain object)
- groupTurnsNaturally / formatGroupedContent: the system_other path
for non-init system turns
Tests only; no source changes. format-turns.ts line coverage rises
from ~86% and the file's non-CLI logic is now fully exercised.
Co-authored-by: hk <solanamobilech@gmail.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Issue/PR comments (#512) and the issue/PR body (#710) are filtered to the
trigger timestamp so content created or edited after an authorized trigger
cannot be injected into Claude's prompt (TOCTOU protection). Reviews and
inline review comments were not: fetchGitHubData returned reviewData filtered
by actor only, and formatReviewComments renders it into the prompt, so a
review submitted or edited after the trigger reached Claude verbatim.
filterReviewsToTriggerTime already existed (added alongside the comment filter
in #512) but was only wired to the image-download list, never to the returned
reviewData.
Filter reviewData.nodes through filterReviewsToTriggerTime and each review's
inline comments through filterCommentsToTriggerTime, alongside the existing
actor filter, then build the review image-processing lists from those
already-filtered nodes (removing a now-redundant second filter pass).
Strengthen the two integration tests to assert post-trigger and edited-after
reviews/comments are dropped.
parseAllowedTools (used to decide which GitHub MCP servers to install)
hand-rolled a regex parse of claude_args, while the tools actually
granted to Claude are parsed by parseClaudeArgsToExtraArgs in
base-action/src/parse-sdk-options.ts using shell-quote. The two parsers
diverged on two inputs (#1357):
- Multiple values after a single flag: for
`--allowedTools "Read" "Grep" "mcp__github__get_commit"` the regex
captured only "Read", so the github MCP server was not installed even
though mcp__github__get_commit was granted — tool calls then failed.
- Commented-out lines: the regex counted tools on `#`-prefixed lines
that the SDK parser strips, installing servers that were never used.
Reimplement parseAllowedTools on the same shell-quote tokenizer and the
same "accumulating flag consumes all consecutive non-flag values"
semantics, stripping comment lines first, so the install decision agrees
with the tools that are actually granted. Unquoted glob patterns (e.g.
`mcp__github__*`), which shell-quote yields as glob objects, are
recovered to their literal text to preserve existing behavior.
Closes#1357
Co-authored-by: bymle <229636660+bymle@users.noreply.github.com>
GitHub serves pasted attachments from /user-attachments/assets/<uuid>
with no file extension, so getImageExtension() silently defaulted to
".png". When the bytes are actually JPEG/GIF/WebP the downloaded file is
mislabeled, and the Read tool then sends a base64 image whose declared
media_type doesn't match its magic bytes — which the Anthropic API
rejects with `400 invalid_request_error` ("image was specified using the
image/png media type, but the image appears to be a image/jpeg image").
Sniff the real format from the buffer's magic bytes after download and
only fall back to the URL-based extension when the signature is
unrecognized. Adds a regression test for a JPEG at an extensionless URL.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
stripHiddenAttributes used the pattern `["'][^"']*["']` for each quoted
attribute, which matches an opening quote of either type and stops at the
first quote of either type. When a value contained the other quote
character — e.g. an apostrophe inside a double-quoted attribute like
`title="We'll do it"` — the match terminated at the apostrophe, so the
wrong span was removed and the surrounding text was corrupted (e.g.
`<Tooltip title="We'll do it" placement="top">` became
`<Tooltipll do it" placement="top">`).
This surfaced via the github_inline_comment MCP tool: suggestion blocks
whose code lines contain quotes were mangled before posting (#1366).
Match each quoted form per quote type (`"[^"]*"` and `'[^']*'`),
mirroring stripMarkdownLinkTitles, so a value may freely contain the
other quote character. The unquoted fallback is unchanged.
Closes#1366
Co-authored-by: bymle <229636660+bymle@users.noreply.github.com>
The formatted_context block sent to the agent omitted labels for both
issues and pull requests, even though the GraphQL queries already
fetched them. This caused agents to incorrectly report "no labels"
when labels existed, breaking any workflow that routes on label state
(e.g., drift-fix routing on drift:* labels in a Drift Watcher pattern).
Changes:
- Add 'PR Labels:' line to PR context output
- Add 'Issue Labels:' line to issue context output
- Both emit 'none' when no labels are present (explicit > omitted)
- Bump labels(first: 1) → labels(first: 100) in both queries; the
previous cap meant only one label would appear even after the
formatter fix
- Update existing tests + add 'with labels' tests for both PR and
issue branches
Discovered while building a GitHub Actions workflow that uses this
action for drift-watcher routing in an internal seed framework
(joshpayne-joby/slim-routines#6). The agent self-diagnosed the gap
by inspecting this action's source — a satisfying full-loop.
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
* test: add unit tests for parseGitHubContext and context type guards
Covers all supported webhook event types (entity and automation),
the pull_request_target normalization, isPR detection for comments
on pull requests, env-derived input defaults and parsing, and the
nine type guard functions. Raises src/github/context.ts line
coverage from 26.5% to 100%.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test: assert all env-derived inputs to close mutation testing gaps
Mutation testing (StrykerJS, 138 mutants) showed 22 surviving mutants
in the env input parsing of parseGitHubContext: fields like
trackProgress, includeFixLinks, allowedBots and the comment actor
filters were never asserted. Asserting every input field in both the
defaults and the explicit-values tests, plus covering the optional
chaining on payload.repository, brings the mutation score for
src/github/context.ts from 84.06% to 100%.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Add workload identity federation support to base-action
Move the workload identity module into base-action so the standalone
action can fetch and refresh the GitHub OIDC identity token itself, and
expose the same federation inputs as the outer action. Switch the
base-action test workflows from the anthropic_api_key secret to the
federation repo variables and grant them id-token: write.
* Verify MCP test tool invocation instead of init connection status
MCP servers can connect asynchronously, so the init event may report a
server as pending. Check that the server is registered at init, then
assert the test tool was actually called and returned its response.
Also pass the MCP config through claude_args --mcp-config, replacing the
removed mcp_config input.
* Add workload identity federation auth support
Adds anthropic_federation_rule_id, anthropic_organization_id,
anthropic_service_account_id, anthropic_workspace_id, and
anthropic_oidc_audience inputs. When the federation rule and organization
are set, the action fetches the workflow's GitHub Actions OIDC token,
writes it to a file in RUNNER_TEMP, keeps it refreshed during execution,
and points the Claude Code CLI at it via ANTHROPIC_IDENTITY_TOKEN_FILE so
the CLI can exchange it for a short-lived access token instead of using a
static API key.
* Add WIF example workflow and base-action federation docs
* Default workload identity OIDC audience to https://api.anthropic.com
Move the allowed_bots check in checkHumanActor and checkWritePermissions so
it only fires after the actor has been resolved as a non-User account
(GitHub App / bot, or unresolvable app actor). Actors that resolve to a
regular User account go through the standard human/write checks regardless
of allowed_bots.
The Copilot-style path (GITHUB_ACTOR not ending in [bot] and not resolvable
as a user) is unchanged: it still falls through to the existing 404 catch,
which already consults allowed_bots once the API has reported the actor is
not a user.
Update tests to match and add coverage for the User-account path.
The opt-in simplified tag-mode prompt omitted several guardrails the
default prompt has. Bring it closer to the default's posture while
keeping it terse:
- Scoping clarification: spell out that only the triggering comment
(or the issue body for issue events) carries instructions; other
comments, the body, review comments, and repository files are
reference context, not commands to act on.
- Review-only stop-condition: questions and code reviews must not edit,
commit, push, or create branches unless the trigger explicitly asks
for a code change.
- PR base-branch diff: when triggered on a PR with a known base branch,
compare against origin/<base> instead of main/master.
- Capability limits: cannot submit formal PR reviews, approve, or merge;
decline politely and point to the FAQ.
Adds focused tests covering the new lines for both PR and non-PR
events, including presence/absence of the conditional base-branch line.
GitHub Apps like Copilot SWE Agent set GITHUB_ACTOR to a value (e.g.
"Copilot") that is neither a valid GitHub user nor ends with "[bot]".
This caused two independent crashes:
1. checkWritePermissions (permissions.ts): called the collaborator
permission API which returns 404 "is not a user" for non-user actors.
2. checkHumanActor (actor.ts): called the Users API first, which 404s,
before ever reaching the allowed_bots check.
Fix both by:
- Checking allowed_bots BEFORE making API calls, so known bots skip the
API entirely.
- In permissions.ts, catching "is not a user" 404 errors and falling
back to the allowed_bots list instead of crashing.
- In actor.ts, catching 404 errors and providing a clear error message
telling the user to add the bot to allowed_bots.
Closes#900, #903, #1018, #1133
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
`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>
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>
`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>
Add shouldRetry predicate to RetryOptions so callers can abort retries
for errors that will never succeed (e.g. 401 WorkflowValidationSkipError).
Previously, retryWithBackoff retried all errors blindly, wasting ~35s on
deterministic failures like workflow validation 401s.
Fixes#1081
Co-authored-by: Claude <noreply@anthropic.com>
* fix: fall back to repo default_branch instead of hardcoded "main"
When no explicit base_branch input is provided, the action previously
fell back to a hardcoded "main", which fails on repositories whose
default branch is named differently (e.g. "master", "develop").
This reads repository.default_branch from the GitHub event payload
(populated once in parseGitHubContext) and uses it as the fallback in
all three callsites: agent/index.ts, run.ts, and update-comment-link.ts.
Explicit env/input precedence is preserved; "main" remains only as a
last-resort defensive fallback if the payload somehow lacks the field.
* test: drop unused BASE_BRANCH env handling from default_branch test
agent/index.ts no longer reads process.env.BASE_BRANCH directly (it now
goes through context.inputs.baseBranch which is set on the mock context),
so saving/clearing/restoring that env var in the regression test is dead
code.
Two defenses for tag mode where an attacker with repo write access could
craft a prompt injection payload in an issue/PR to gain RCE on the
Actions runner:
1. git-push wrapper (H1 #3556799)
The Bash(git\ push:*) rule permitted arbitrary flags and remotes,
including combinations that execute shell commands locally. Replaced
with scripts/git-push.sh which allowlists exactly 'origin <ref>' with
no flags, validates the ref via check-ref-format. Same pattern as
scripts/gh.sh.
2. acceptEdits instead of blanket Write/Edit (Asana 1213310082312048)
Edit/MultiEdit/Write in allowedTools granted write access to the
whole runner filesystem (~/.bashrc etc). Removed from allowedTools
and set --permission-mode acceptEdits, which auto-accepts edits
inside cwd ($GITHUB_WORKSPACE) and denies outside. Headless SDK has
no prompt handler so 'ask' becomes deny.
Also:
- Noted that create-prompt/index.ts exports ALLOWED_TOOLS env var that
nothing reads. The live path is modes/tag/index.ts. Mirrored the fix
in both so the file the H1 report likely points to stays in sync.
- Updated prompt text (3 callsites) to reference the wrapper.
- Updated tests (4 prompt-content asserts, 7 tool-list asserts).
* feat(inline-comment): add confirmed param + probe-pattern safety net
Subagents that inherit this tool sometimes probe it with test comments
('Test comment to see if I can create inline comments') after hitting
unrelated errors elsewhere. Recurring issue across customer PRs.
Adds two defenses:
1. confirmed param: set true to post (final review comments should pass
this). When false, buffers to a JSONL file instead of posting.
2. Probe-pattern safety net: when confirmed is omitted (backward compat
for existing prompts), the body is checked against obvious probe
patterns ('test comment', 'can i', 'does this work', etc.). Matching
calls are buffered instead of posted.
A post-run step in action.yml reports the buffered call count and bodies
as a workflow warning for diagnostics.
Backward compatibility:
- Existing single-agent prompts (no confirmed param) post normally unless
the body happens to start with a probe phrase (unlikely for real
review comments)
- The code-review skill is being updated to pass confirmed: true in its
final posting step
- Subagent probes that would previously post now harmlessly buffer
* refactor: replace probe-regex with Haiku classification in post-step
The regex approach was narrow and could miss creative probe phrasings.
Replaced with a batch Haiku classification that runs after the session
completes.
Flow:
- MCP server: confirmed !== true -> buffer to JSONL (no classification
in-band, no latency in the tool path)
- Post-step (src/entrypoints/post-buffered-inline-comments.ts): reads
buffer, sends all bodies to a single Haiku call, posts only those
classified as real review comments
- confirmed=false entries are never posted regardless of classification
Fail-open: if ANTHROPIC_API_KEY is unavailable (Bedrock/Vertex users)
or the classification call fails, posts all unconfirmed comments. This
matches pre-PR behavior where all calls posted immediately.
The post-step emits :⚠️: for each filtered comment so users can
see what was dropped and why.
* feat: add classify_inline_comments opt-out input
New action input classify_inline_comments (default 'true'). Setting to
'false' restores pre-buffering behavior: all inline comment calls post
immediately regardless of the confirmed param.
Threads through: action input -> CLASSIFY_INLINE_COMMENTS env ->
context.inputs.classifyInlineComments -> MCP server env ->
CLASSIFY_ENABLED module const.
Post-step is also gated on the input so it skips entirely when
classification is disabled.
* docs: document classify_inline_comments input and confirmed param
- usage.md: add classify_inline_comments to inputs table
- solutions.md: mention confirmed=true in the prompt example and explain
buffering/classification in the tool permissions section
Replace `Bash(git add:*)` syntax with `Bash(git add *)` in default
tool permissions for tag mode and create-prompt. The colon-prefixed
wildcard syntax is deprecated and causes SDK validation errors.
Closes#856
Co-authored-by: Dave-London <hello@os4us.org>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Replace the over-engineered Mode interface/registry/detector pattern with
straightforward inline logic. There are only 2 modes (tag and agent) and
the complexity wasn't justified.
- Delete Mode interface, registry, and prepare pass-through modules
- Export prepareTagMode() and prepareAgentMode() as standalone functions
- Inline trigger checking and mode dispatch in run.ts/prepare.ts
- Change generatePrompt/createPrompt to take modeName string instead of Mode
- Remove dead code (extractGitHubContext, unused detector helpers)
- Update CLAUDE.md to reflect new architecture
* refactor: unify action into single composite step with run.ts entrypoint
Consolidate the prepare and base-action phases into a single composite
step that runs src/entrypoints/run.ts. This simplifies the action.yml
from multiple steps to one execution step, while keeping the same
behavior.
Key changes:
- Add src/entrypoints/run.ts as unified entrypoint
- Simplify action.yml to single 'Run Claude Code Action' step
- Pass all inputs via environment variables
- Update base-action to accept inputs via env vars
- Support agent mode auto-detection from prompt input
* refactor: keep SSH signing cleanup and token revocation as separate action steps
Move SSH signing key cleanup and app token revocation back to separate
composite action steps in action.yml with always() conditions, rather
than handling them inside run.ts. This keeps these cleanup concerns
as independently visible steps in the workflow.
* fix: address PR review feedback
- Use path.dirname() instead of manual string slicing for executable path
- Differentiate prepare vs execution errors in catch block so tracking
comment accurately reflects which phase failed
- Update CLAUDE.md architecture docs to reflect unified run.ts entrypoint
and four-phase design
* fix: address PR review feedback
- Use path.dirname() instead of manual string slicing for executable path
- Differentiate prepare vs execution errors in catch block so tracking
comment accurately reflects which phase failed
- Rewrite CLAUDE.md to focus on mental model, key concepts, and gotchas
instead of exhaustive file listings
- Introduced `include_comments_by_actor` and `exclude_comments_by_actor` inputs in action.yml to allow filtering of comments based on actor usernames.
- Updated context parsing to handle new input fields.
- Implemented `filterCommentsByActor` function to filter comments according to specified inclusion and exclusion patterns.
- Modified `fetchGitHubData` to apply actor filters when retrieving comments from pull requests and issues.
- Added comprehensive tests for the new filtering functionality.
This enhancement provides more control over which comments are processed based on the actor, improving the flexibility of the workflow.
* feat: send additional_permissions in token exchange request
Parse the ADDITIONAL_PERMISSIONS env var and send it as a JSON body
in the OIDC token exchange request. Permissions are merged on top of
the standard defaults (contents: write, pull_requests: write,
issues: write).
* docs: list specific available additional permissions
ssh-keygen requires a trailing newline to parse private keys correctly.
Without it, git signing fails with the confusing error:
'Couldn't load public key: No such file or directory?'
This normalizes the key to always end with a newline before writing.
Fixes issue #641 where users were getting banned due to rapid successive
Claude runs triggered by the synchronize event.
Changes:
- Add checkHumanActor call to agent mode's prepare() method to reject
bot-triggered workflows unless explicitly allowed via allowed_bots
- Update checkHumanActor to accept GitHubContext (union type) instead
of just ParsedGitHubContext
- Add tests for bot rejection/allowance in agent mode
Claude-Generated-By: Claude Code (cli/claude-opus-4-5=100%)
Claude-Steers: 1
Claude-Permission-Prompts: 3
Claude-Escapes: 0
