Previously, prompt files at `${RUNNER_TEMP}/claude-prompts/` from a prior
invocation could persist on non-ephemeral self-hosted runners (where the
documented `RUNNER_TEMP` cleanup contract is not reliably honored). In
particular, `claude-user-request.txt` is only written by `create-prompt`
when a user request exists; an `agent`-mode invocation does not overwrite
it, so a stale value left by an earlier mention-mode job in another repo
would leak into a later agent-mode job's effective context on the same
runner agent.
Fix: `rm -rf` the directory before `mkdir` in both write sites
(`src/create-prompt/index.ts`, `src/modes/agent/index.ts`). Idempotent,
safe on hosted runners (where the dir is already empty), and self-heals
on self-hosted runners.
Closes#1287
In some workflow contexts — reliably reproducible for us on
pull_request-triggered runs of this action — the Claude Agent SDK
query() async iterator does not close after the terminal result
message is emitted. The for-await loop in runClaudeWithSdk blocks
indefinitely after Claude has finished its work, until the workflow's
timeout-minutes cap kills the job.
Symptoms observed in production (4× in our scan-reviewer workflow):
- Claude completes successfully: SDK emits { type: "result",
subtype: "success", ... } with the cost / turns / duration set.
- The action then sits with zero log output for the rest of
timeout-minutes (we measured 18-19 min of dead time after result).
- The job is cancelled at timeout. writeExecutionFile is never
called → no claude-execution-output.json → cost-tracker and other
post-steps see nothing.
- Run shows as cancelled, even though Claude did its work and any
verdict it posted via gh tools already landed.
Author-mode (workflow_dispatch) runs from the same codebase
terminate cleanly the same day, so the hang is specific to certain
event triggers.
By SDK contract the result message is terminal — no further messages
follow. Break out of the loop immediately after capturing it,
regardless of whether the upstream iterator ever closes. If the SDK
is later fixed to close cleanly in all contexts, this break becomes
a no-op.
The "Run Claude Code Action" step maps the auth inputs into env
unconditionally:
ANTHROPIC_API_KEY: ${{ inputs.anthropic_api_key }}
CLAUDE_CODE_OAUTH_TOKEN: ${{ inputs.claude_code_oauth_token }}
When the input is empty — whether because the caller supplied auth via
the step `env:` block (as reported in #676) or because the `with:` value
resolves empty in some runner/secret configurations — this assignment
overwrites the inherited env value with an empty string. validate-env
then fails with the misleading "Either ANTHROPIC_API_KEY or
CLAUDE_CODE_OAUTH_TOKEN is required" error even though the caller did
provide a token.
Fall back to the inherited env var when the input is empty, mirroring the
existing `${{ env.X }}` pattern already used a few lines below for
ANTHROPIC_BASE_URL / ANTHROPIC_CUSTOM_HEADERS. The input still takes
precedence; nothing changes for workflows that pass auth via `with:`.
Fixes#676
The "Why won't Claude rebase my branch?" FAQ told users they could
enable rebasing by passing `--allowedTools "Bash(git rebase:*)"` via
claude_args. This does not work: the system prompt built in
src/create-prompt/index.ts unconditionally instructs Claude that it
cannot merge, rebase, or perform branch operations beyond creating and
pushing commits, so Claude declines rebase requests regardless of the
allowed tools.
Update the FAQ to describe the actual behavior and point users to the
real workaround (rebase locally or via the Claude Code CLI).
Closes#1286
Co-authored-by: bymle <229636660+bymle@users.noreply.github.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>
* Drop --tsconfig-override from Bun invocations to avoid runtime crash
Passing --tsconfig-override to `bun run` triggers a Bun runtime bug
("Internal error: directory mismatch for directory .../tsconfig.json")
that aborts the action with exit code 1 before any work is done.
Bun already auto-discovers the action's own tsconfig.json by walking up
the directory tree from the entry file, so the override is redundant —
the workspace's tsconfig is never an ancestor of the action checkout.
Dropping the flag preserves tsconfig resolution while avoiding the crash.
Refs: oven-sh/bun#25730https://claude.ai/code/session_01L763e4S7zBnzDqmYYEJS1A
* Fix prettier formatting in create-prompt/index.ts
Removes redundant outer parentheses that were tripping format:check.
Pre-existing on main; unrelated to the action.yml change but needed
to keep CI green on this branch.
https://claude.ai/code/session_01L763e4S7zBnzDqmYYEJS1A
---------
Co-authored-by: Claude <noreply@anthropic.com>
actions/checkout v4 and oven-sh/setup-bun v2.0.2 run on the deprecated
Node 20 action runtime and emit a deprecation warning on every run.
Bump to checkout v6.0.2 and setup-bun v2.2.0 (both Node 24).
Co-authored-by: ant-kurt <209710463+ant-kurt@users.noreply.github.com>
* chore: bump actions/setup-node from v4.4.0 to v6.4.0 (Node.js 24)
setup-node v4 runs on the deprecated Node.js 20 action runtime, producing
a deprecation warning on every workflow run that uses base-action. v6 runs
on Node 24. This only changes the action's own runtime — the node-version
it installs for user code is unaffected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Disable setup-node v5+ automatic package-manager caching
Preserves v4 behavior: caching only when use_node_cache=true.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: ant-kurt <209710463+ant-kurt@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <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.
Switch claude.yml, claude-review.yml, and issue-triage.yml from the
anthropic_api_key secret to the workload identity federation inputs.
The federation rule, organization, and service account IDs are read
from repository variables; issue-triage.yml additionally gains the
id-token: write permission required to request the OIDC token.
* 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.
`??` has lower precedence than `!==`, so the expression:
triggerDisplayName ?? triggerUsername !== "Unknown"
parses as:
triggerDisplayName ?? (triggerUsername !== "Unknown")
When triggerDisplayName is an empty string "", the condition
evaluates to "" (falsy), incorrectly skipping the co-author line
even though the user is not "Unknown".
Add parentheses to get the intended behavior:
(triggerDisplayName ?? triggerUsername) !== "Unknown"
Co-authored-by: Rush <rush@RushdeMacBook-Pro.local>
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>
