Bug

claude-code-action v1.0.74+ (PR #1066) introduced the restoreConfigFromBase feature that restores .claude/, .mcp.json, .claude.json, .gitmodules, and .ripgreprc from the PR base branch before running the CLI.

In repositories that contain .gitmodules (with git submodules), this restore step hangs indefinitely with no output and no error.

Environment

• Runner: self-hosted macOS ARM64
• Repository has .gitmodules with submodules
• PR base branch: release/5.1.0 (non-main)
• claude-code-action: @v1 (resolved to SHA df37d2f0, v1.0.75)
• Claude Code: 2.1.79
• Agent SDK: 0.2.79

Steps to Reproduce

1. Have a repository with .gitmodules (git submodules configured)
2. Create a PR targeting a non-main branch (e.g., release/5.1.0)
3. Trigger claude-code-action@v1 (v1.0.74+)
4. Observe the restoreConfigFromBase step

Expected Behavior

The restore step completes (or fails with an error) within a reasonable time.

Actual Behavior

The step hangs indefinitely after printing:

Restoring .claude, .mcp.json, .claude.json, .gitmodules, .ripgreprc from origin/release/5.1.0 (PR head is untrusted)

No further output is produced. The job ran for ~4 hours until manually cancelled.

Logs

Last output before hang:

2026-03-19T09:13:13.0854080Z Claude Code installed successfully
2026-03-19T09:13:13.0864890Z Restoring .claude, .mcp.json, .claude.json, .gitmodules, .ripgreprc from origin/release/5.1.0 (PR head is untrusted)
2026-03-19T13:11:45.8391970Z ##[error]The operation was canceled.

Previous run with v1.0.73 (SHA cd77b50d, before PR #1066) completed successfully in ~20 minutes. No "Restoring" step was present.

Difference from #1080

Issue #1080 reports that restoreConfigFromBase fails with fatal: couldn't find remote ref main when the default branch is not main. This issue is different:

• restoreConfigFromBase fails on repos with non-"main" default branch #1080: The step errors out (fails fast) due to hardcoded "main" fallback
• This issue: The step hangs silently — no error, no output, no timeout

The hang may be caused by the git operations involved in restoring .gitmodules triggering submodule-related git commands (e.g., git submodule update) that block waiting for network/authentication input.

Workaround

Pin to a commit before PR #1066:

uses: anthropics/claude-code-action@cd77b50d2b0808657f8e6774085c8bf54484351c # v1.0.73

Question

What is the recommended way to determine when it is safe to unpin? Specifically:

• Is there a test or release note we can watch for that confirms the .gitmodules hang is fixed?
• Would adding a timeout to the restore step itself (independent of the job-level timeout-minutes) be a reasonable safeguard?

Related

• Restore .claude/ and .mcp.json from PR base branch before CLI runs #1066 — PR that introduced restoreConfigFromBase
• restoreConfigFromBase fails on repos with non-"main" default branch #1080 — restoreConfigFromBase fails on repos with non-"main" default branch
• restoreConfigFromBase fails on issue_comment events when default branch is not main #1085 — restoreConfigFromBase fails on issue_comment events
• fix: use repo default branch instead of hardcoded 'main' in agent mode #1083 — Fix PR (uses repository.default_branch instead of hardcoded "main")