Summary

• Problem: runtime dependency fingerprinting trusted Dirent.isSymbolicLink() before checking the actual filesystem entry.
• Why it matters: on Windows, pnpm-materialized files can be reported as symlink-like at the Dirent layer, causing readlinkSync() to throw while staging bundled plugin runtime deps.
• What changed: re-check each path with lstatSync() before symlink/file/directory handling and use that stat for file size fingerprinting.
• What did NOT change (scope boundary): no dependency resolution, install, package manifest, or runtime output behavior beyond avoiding the false-positive readlink path.

Change Type (select all)

• Bug fix
• Chore/infra

Scope (select all touched areas)

• CI/CD / infra

Linked Issue/PR

• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the fingerprint walker used fs.readdirSync(..., { withFileTypes: true }) Dirent classification as the source of truth, then called readlinkSync() for entries reported as symbolic links.
• Missing detection / guardrail: there was no regression test for a Dirent symlink false positive where lstat() reports a regular file.
• Contributing context (if known): Windows + pnpm dependency trees can surface this mismatch while staging bundled plugin runtime dependencies.

Regression Test Plan (if applicable)

• Coverage level that should have caught this: Unit test
• Target test or file: test/scripts/stage-bundled-plugin-runtime-deps.test.ts
• Scenario the test should lock in: a Dirent reports package.json as a symlink but lstat() reports it as a normal file, so staging should not call readlinkSync() for that path.
• Why this is the smallest reliable guardrail: it isolates the filesystem classification mismatch without depending on a specific pnpm install layout.

User-visible / Behavior Changes

None.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Windows
• Runtime/container: Node 22 / local checkout
• Model/provider: N/A
• Integration/channel (if any): bundled plugin runtime dependency staging
• Relevant config (redacted): N/A

Steps

1. Run the focused regression test.
2. Run the whole touched test file.
3. Check the diff for whitespace errors.

Expected

• The focused regression passes and no whitespace errors are reported.

Actual

• Focused regression passed.
• git diff --check origin/main...HEAD passed.
• The full touched test file runs 24 passing tests, including the new regression, but 5 existing symlink-security tests are blocked on this Windows shell because fs.symlinkSync(...) returns EPERM: operation not permitted before assertions run.

Evidence

• Failing test/log before + passing after

Human Verification (required)

• Verified scenarios: pnpm exec vitest run --config test/vitest/vitest.tooling.config.ts test/scripts/stage-bundled-plugin-runtime-deps.test.ts -t "ignores dirent symlink false positives"; git diff --check origin/main...HEAD.
• Edge cases checked: readlinkSync() is not called for the false-positive package file, and staging still copies the runtime dependency file.
• What you did not verify: full file green on Windows, because existing symlink tests need symlink privileges and fail with EPERM in this shell.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

None.