Skip to content

init misreports the failed .agents/skills symlink on Windows (EPERM, not a filesystem limitation); a junction would work #230

Description

@Julian-Genuario

Summary

On Windows, init prints

! .agents/skills symlink could not be created (filesystem without symlink support) — skipped.

The filesystem supports symlinks; what fails is symlinkSync(..., "dir") with EPERM, because Windows only grants SeCreateSymbolicLinkPrivilege to administrators or with Developer Mode on. A directory junction needs no privilege and works for this purpose:

> node -e "fs.symlinkSync('../.claude/skills','.agents/skills','dir')"
code: EPERM | EPERM: operation not permitted, symlink '..\.claude\skills' -> '...\.agents\skills'
> node -e "fs.symlinkSync('../.claude/skills','.agents/skills','junction')"
junction OK

Where

src/init.mjs:513-519 catches every error from symlinkSync and reports the same message.

Why it matters

.agents/skills is how non-Claude tooling discovers the vendored skills (init.mjs:507, concepts/method.md:153, validate-delivery-loop.md:186), so on a Windows workstation the Codex lane runs without them and the warning points the user at the wrong cause.

Fix

On EPERM, retry with type: "junction" (Node resolves the target to an absolute path for junctions, which is fine here); if that fails too, print the actual error code instead of guessing. One-line change plus a test that asserts either a symlink or a junction exists after init on win32. Happy to open the PR.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions