fix: fall back to repo default_branch instead of hardcoded "main" by ashwin-ant · Pull Request #1143 · anthropics/claude-code-action

ashwin-ant · 2026-04-01T19:58:31Z

Fixes #1080
Fixes #1085
Supersedes #1083

When no explicit base_branch input is provided, the action previously fell back to a hardcoded "main", causing restoreConfigFromBase (and PR-link generation) to fail 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() so no extra API call is needed — and uses it as the fallback in all three callsites:

src/modes/agent/index.ts
src/entrypoints/run.ts
src/entrypoints/update-comment-link.ts

(#1083 only patched agent/index.ts.)

Explicit env/input precedence is preserved; "main" remains only as a last-resort defensive fallback if the payload somehow lacks the field. Also drops the redundant process.env.BASE_BRANCH read in agent/index.ts since context.inputs.baseBranch already mirrors it.

A regression test in test/modes/agent.test.ts asserts a default_branch: "develop" repo flows through to branchInfo, so CI fails if this fallback is ever reverted.

Note: for the issue_comment-on-PR edge case in agent mode, the restore now uses the repo's default branch rather than the PR's actual base ref — still secure (trusted branch), and matches the existing accepted-risk comment in run.ts. Fetching the true base ref via API for that case is a possible follow-up.

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.

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.

claude

LGTM — clean, focused fix with consistent changes across all three callsites and a regression test.

Extended reasoning...

Overview

This PR adds default_branch to the repository field in BaseContext, populates it from context.payload.repository?.default_branch in parseGitHubContext(), and uses it as the fallback (before the hard-coded "main" last resort) in three places: agent/index.ts, run.ts, and update-comment-link.ts. It also removes a redundant process.env.BASE_BRANCH read in agent/index.ts since context.inputs.baseBranch already mirrors that env var. A regression test exercises the default_branch: "develop" path.

Security risks

No security concerns. repository.default_branch comes from the same GitHub event payload already used for owner, repo, and full_name — all trusted values. The "main" last-resort fallback is preserved for edge cases where the field is absent.

Level of scrutiny

Low — this is a narrow bug fix that only changes the default-branch fallback logic. No new API calls, no auth/permission changes, no architectural decisions. The change is mechanical and consistent across all affected callsites.

Other factors

The PR correctly notes the accepted-risk edge case (issue_comment-on-PR using repo default branch instead of PR base ref) and acknowledges it as a known pre-existing trade-off. Test coverage is solid: the new test clears all overriding env vars and asserts "develop" flows through to branchInfo.

claude

LGTM — clean, consistent fix across all three callsites with a defensive || "main" fallback retained.

Extended reasoning...

Overview

This PR adds default_branch to the repository context object (parsed once from the GitHub event payload) and threads it through three fallback callsites in agent/index.ts, run.ts, and update-comment-link.ts, replacing a hardcoded "main". A new regression test asserts the develop case propagates correctly.

Security risks

No security concerns. default_branch is sourced from the trusted GitHub event payload, gated behind ?. optional chaining, and always has || "main" as a last-resort defensive fallback. The comment in run.ts correctly documents the accepted-risk edge case for issue_comment-on-PR where the restore uses the repo default branch rather than the PR base ref.

Level of scrutiny

Low — this is a straightforward bug fix. Each change is a one-liner substituting an existing || "main" sentinel with || context.repository.default_branch || "main". No logic changes, no new API calls, no auth/permission paths touched.

Other factors

The sole bug reported (missing CLAUDE_ARGS save/restore in the new test) is a nit: it only manifests if the preceding test fails mid-body before its inline cleanup, and even then the leaked value does not affect the new test's assertions (which only check branchInfo fields). The inline comments already capture this. The PR is well-scoped, drops a redundant process.env.BASE_BRANCH read that was shadowed by context.inputs.baseBranch, and includes a regression test to guard against reversion.

claude · 2026-04-01T20:16:20Z

+      eventName: "workflow_dispatch",
+      repository: {
+        owner: "test-owner",
+        repo: "test-repo",
+        full_name: "test-owner/test-repo",
+        default_branch: "develop",
+      },
+    });


🟡 The new test "prepare falls back to repository.default_branch when not 'main'" does not save/restore CLAUDE_ARGS, unlike the adjacent test that explicitly manages it. If the preceding test fails at an assertion before its delete process.env.CLAUDE_ARGS cleanup (line 104), the leaked value would flow into prepareAgentMode and appear in claudeArgs output — though the test assertions only cover branchInfo fields so they would still pass.

Extended reasoning...

Analysis

The new test added at lines 113-163 of test/modes/agent.test.ts does not save or restore CLAUDE_ARGS, unlike the immediately preceding test "prepare passes through claude_args" which explicitly sets process.env.CLAUDE_ARGS = "--model claude-sonnet-4 --max-turns 10" and cleans it up with delete process.env.CLAUDE_ARGS at the end of the test body.

How the bug manifests

In src/modes/agent/index.ts, CLAUDE_ARGS is read unconditionally: const userClaudeArgs = process.env.CLAUDE_ARGS || "";. This value flows into the claudeArgs return field. If the preceding test fails mid-execution — for example, if one of its expect() assertions throws before reaching the cleanup block — CLAUDE_ARGS remains set in the process environment and is inherited by the new test.

Why existing code doesn't prevent it

The test cleanup for CLAUDE_ARGS in the preceding test is done inline in the test body (not in afterEach), so it is not guaranteed to run on failure. The afterEach hook only restores spies, not environment variables. This is a gap that the new test inherits rather than defending against.

Impact

If the leak occurs, prepareAgentMode will include --model claude-sonnet-4 --max-turns 10 in its claudeArgs output instead of an empty string. The new test only asserts on result.branchInfo.baseBranch and result.branchInfo.currentBranch, which are derived from context.repository.default_branch — completely unaffected by CLAUDE_ARGS. So the test passes even with leaked state, silently masking the unexpected behavior. This is a test quality/robustness issue, not a correctness issue for production code.

Addressing the refutation

The refutation correctly notes that (a) the prior test does clean up CLAUDE_ARGS under normal execution, and (b) the new test's assertions are unaffected by CLAUDE_ARGS. Both points are true. However, the fragility comes from the failure path: if the prior test throws before line 104, cleanup is skipped. The refutation does not address this failure-path scenario. The inconsistency with the surrounding cleanup pattern is also a readability/maintenance concern — future readers may not realize this test is not defensive against env leakage.

Proof of fragility

Step-by-step: (1) Prior test sets process.env.CLAUDE_ARGS = "--model claude-sonnet-4 --max-turns 10". (2) An assertion in the prior test fails, throwing before delete process.env.CLAUDE_ARGS at line 104. (3) The new test runs with CLAUDE_ARGS still set. (4) prepareAgentMode reads CLAUDE_ARGS and builds claudeArgs = "--model claude-sonnet-4 --max-turns 10". (5) The new test assertions expect(result.branchInfo.baseBranch).toBe("develop") and expect(result.branchInfo.currentBranch).toBe("develop") both pass since CLAUDE_ARGS does not affect branch info. (6) The test suite reports a passing test, but the behavior being tested has unexpected side effects that go undetected.

Fix

Add const originalClaudeArgs = process.env.CLAUDE_ARGS; before the test body and restore/delete it in the cleanup block alongside the other env var restorations, matching the pattern used in the same test for CLAUDE_BRANCH, GITHUB_HEAD_REF, and GITHUB_REF_NAME.

ashwin-ant added 2 commits April 1, 2026 12:58

claude Bot reviewed Apr 1, 2026

View reviewed changes

wolffiex approved these changes Apr 1, 2026

View reviewed changes

ashwin-ant merged commit c281e17 into main Apr 1, 2026
41 checks passed

ashwin-ant deleted the fix/default-branch-fallback branch April 1, 2026 21:48

github-actions Bot mentioned this pull request Apr 7, 2026

chore(deps): update anthropics/claude-code-action action to v1.0.85 lacolaco/blog.lacolaco.net#1445

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: fall back to repo default_branch instead of hardcoded "main"#1143

fix: fall back to repo default_branch instead of hardcoded "main"#1143
ashwin-ant merged 2 commits intomainfrom
fix/default-branch-fallback

ashwin-ant commented Apr 1, 2026

Uh oh!

claude Bot left a comment

Uh oh!

claude Bot left a comment

Uh oh!

claude Bot Apr 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

ashwin-ant commented Apr 1, 2026

Uh oh!

claude Bot left a comment

Choose a reason for hiding this comment

Overview

Security risks

Level of scrutiny

Other factors

Uh oh!

claude Bot left a comment

Choose a reason for hiding this comment

Overview

Security risks

Level of scrutiny

Other factors

Uh oh!

claude Bot Apr 1, 2026

Choose a reason for hiding this comment

Analysis

How the bug manifests

Why existing code doesn't prevent it

Impact

Addressing the refutation

Proof of fragility

Fix

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants