[BUG] SessionStart hook fails with EEXIST when plugin data dir is a Windows symlink/junction

Resolved 💬 3 comments Opened May 8, 2026 by m-nakamura27 Closed May 11, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, if ~/.claude/plugins/data/<plugin-id> is a symbolic link
(ReparsePoint) — e.g. redirected to OneDrive for sync — Claude Code's
SessionStart routine fails with:

SessionStart:startup hook error
└ Failed to run: EEXIST: file already exists,
mkdir 'C:\Users<user>.claude\plugins\data\superpowers-claude-plugins-official'

The plugin itself loads and works correctly; this is purely a startup warning.

What Should Happen?

fs.mkdir(path, { recursive: true }) should be idempotent. On Windows,
Node treats reparse points as already-existing non-directory entries,
so the recursive flag does not silently succeed. The startup code should
either:

  • check lstat and follow the link before mkdir, or
  • swallow EEXIST when the path resolves to an existing directory.

Error Messages/Logs

SessionStart:startup hook error
  └ Failed to run: EEXIST: file already exists,
    mkdir 'C:\Users<user>.claude\plugins\data\superpowers-claude-plugins-official'

Steps to Reproduce

  1. Install any plugin (e.g. superpowers@claude-plugins-official).
  2. Replace ~/.claude/plugins/data/<plugin-id> with a directory symlink

(PowerShell: New-Item -ItemType SymbolicLink ... or mklink /D)
pointing to a valid existing directory.

  1. Start Claude Code → the EEXIST error appears at startup.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.133

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

## Environment

  • Claude Code: v2.1.133
  • OS: Windows 11 Pro 10.0.26200
  • Shell: PowerShell

## Notes

  • Symlink target is accessible and the plugin functions normally.
  • Same issue likely affects junctions (mklink /J) created by users who

redirect plugin data to OneDrive / Dropbox / external drives.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗