cpSync fails on symlinked sensitive files

[corygabrielsen]

Summary

anthropics/claude-code-action@v1 fails with ENOENT: no such file or directory, symlink during the "Restoring sensitive files from origin/master" step when any of the enumerated sensitive paths is a git-tracked symlink.

In our repo, CLAUDE.md is a symlink to AGENTS.md. Every Code Review run fails. The failure is 100% reproducible, not intermittent — it is specifically the symlink cpSync path (#1187) crashing because the restore step treats CLAUDE.md as a real file.

This is likely the same root cause as #1205 ("directory mismatch for tsconfig.json") — once cpSync throws, the Bun runtime leaves a dangling fd that produces the tsconfig error on the next invocation.

Reproduction

Any repo where a sensitive path (CLAUDE.md, .claude, .mcp.json, .claude.json, .husky, etc.) is a symlink tracked in git.

$ ls -la CLAUDE.md
lrwxrwxrwx 1 cory cory 9 Apr  7 22:08 CLAUDE.md -> AGENTS.md

Failing run

Log excerpt

Claude Code installed successfully
Restoring .claude, .mcp.json, .claude.json, .gitmodules, .ripgreprc, CLAUDE.md, CLAUDE.local.md, .husky from origin/master (PR head is untrusted)
##[error]Action failed with error: ENOENT: no such file or directory, symlink
Internal error: directory mismatch for directory "/home/runner/_work/_actions/anthropics/claude-code-action/v1/tsconfig.json", fd 4. You don't need to do anything, but this indicates a bug.
##[error]Process completed with exit code 1.

Note the message order: the ENOENT symlink error comes first, then the "directory mismatch for tsconfig.json" surfaces as a secondary fault from the leaked fd. The cascade makes #1205's symptom look like a tsconfig problem when it's really the same symlink issue as #1187.

Environment

• Runner: ubuntu-latest
• Action ref: anthropics/claude-code-action@v1 (currently resolving to v1.0.95)
• Workflow: pull_request trigger, base_ref = master, untrusted PR head path

Expected behavior

Either:

1. Restore the symlink as a symlink (preserve readlink target), or
2. Resolve the symlink to its target and copy the resolved file, or
3. Skip symlinks during restore with a warning.

Suggested fix

In whatever wraps cpSync for the sensitive-file restore, pass { verbatimSymlinks: true } (or equivalent) instead of { recursive: true } alone, or handle EISLINK / symlink entries explicitly before calling cpSync.

Workaround

No workaround. This is due to non-adoption of AGENTS.md standard. Product is fully broken and untested for this use case.