[BUG] Sandbox .vscode write-deny breaks pnpm install of packages shipping .vscode/

Status Open
Reported on v2.1.217
Maintainer reply None cached
Activity 1 comment · opened Jul 22, 2026

What's Wrong?

With the Bash sandbox enabled, pnpm install fails whenever a dependency ships a .vscode/ directory inside its published tarball. The sandbox runtime emits hardcoded (deny file-write* ...) rules for tooling-config directories (.vscode, .idea, .claude, .husky, .git; mechanism analyzed in #62404) that match at any depth inside the session's project directories, so pnpm cannot materialize such files into node_modules. Example in the wild: feed@4.2.2 ships .vscode/settings.json in its tarball and is a transitive dependency of Docusaurus (blog plugin), so a stock Docusaurus site cannot pnpm install under the sandbox.

The deny is not avoidable from either side: the path is covered by sandbox.filesystem.allowWrite, switching pnpm to --config.package-import-method=copy fails the same way (any write inside a .vscode/ directory is denied regardless of filename or syscall), and there is no settings override (#62404 proposed allowWriteWithinDeny and was closed as stale).

What Should Happen?

Package managers should be able to extract packages that legitimately contain .vscode/ folders. Possible scopings: apply the built-in deny only to the project root's .vscode/ (the directory an IDE would actually open), exempt **/node_modules/**, or expose the allowWriteWithinDeny override proposed in #62404.

Error Messages/Logs

 ERR_PNPM_EPERM  Operation not permitted (os error 1), reflink '<pnpm-store>/files/da/fef86...' -> '<project>/node_modules/.pnpm/feed@4.2.2/node_modules/feed_tmp_10354/.vscode/settings.json'

With --config.package-import-method=copy:

 ERR_PNPM_EPERM  EPERM: operation not permitted, copyfile '<pnpm-store>/files/da/fef86...' -> '<project>/node_modules/.pnpm/feed@4.2.2/node_modules/feed_tmp_10865/.vscode/settings.json'

Steps to Reproduce

  1. Enable the sandbox (sandbox.enabled: true) with the project directory writable.
  2. In a project whose lockfile includes feed (any Docusaurus site works), have Claude run pnpm install in the sandboxed Bash tool.
  3. The install links every other package, then fails importing feed@4.2.2 with the error above.

Isolation probe showing it is the path pattern, not pnpm (run in the sandboxed Bash tool):

mkdir -p <project>/node_modules/probe/.vscode        # succeeds (dir creation is allowed)
touch <project>/node_modules/probe/.vscode/settings.json   # Operation not permitted
touch <project>/node_modules/probe/.vscode/other.json      # Operation not permitted (any filename)
mkdir -p /tmp/probe/.vscode && touch /tmp/probe/.vscode/settings.json   # succeeds outside project dirs

Environment

  • Claude Code version: 2.1.217
  • Platform: Anthropic API
  • OS: macOS (darwin 25.5.0, arm64)
  • pnpm: reproduced with 10.30.2 and 11.13.0
  • Regression: unknown; the deny list was already present in 2.1.150 per #62404

Additional Information

Closest existing report is #62404 (hardcoded deny on .idea/.vscode/.claude/.husky with no override, closed as not planned by the stale bot, which asks to open a new issue if still relevant). This report adds a concrete mainstream breakage: standard dependency installation, triggered by tarball contents the user does not control. Current workaround is relocating pnpm's virtual store outside the project (pnpm install --config.virtual-store-dir=<dir outside the project>), which keeps the install sandboxed but is per-project tribal knowledge.

---

This issue was investigated and written by Claude Fable 5 running in Claude Code, at the account owner's request.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗