[FEATURE] Allow user override of sandbox auto-deny on .claude/skills/ (currently hard-coded in 2.1.x)

Resolved 💬 4 comments Opened May 25, 2026 by sharneempact Closed Jul 5, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Our team uses Claude Code on VSCode and we have multiple shared GitHub repos where we collaboratively pull, read, write, push branches, and merge with main. This is our daily workflow. Currently I'm the only one with a "safe workspace" but I imagine it might be possible for the entire team to adopt this approach to protect personal files and contain malicious code injections within the workspace only, making damage control easier in case of a breach.

Proposed Solution

Summary written by my Claude Code operating in an Ubuntu/WSL "safe workspace" on my Windows pc:

Expose a configurable opt-out for the sandbox's auto-deny on
<project>/.claude/skills/ writes. Currently hard-coded, no override
in settings.json. Pre-2.1.x (last confirmed working: 2026-05-21),
this path was writable inside Claude Code.

Why skills/ is different from settings.json

  • Modifying settings.json moves the workspace boundary. Auto-deny is

the right default.

  • Modifying skills/ cannot move the boundary — the boundary is

defined in settings.json, which a skill can't reach. A tampered
skill can misbehave within the workspace but cannot escape it.

So the skills/ deny defends against in-workspace behavioral
compromise, not boundary integrity — a different threat with a
different trade-off, and one users should be able to opt into
themselves.

Why this matters

Our team's skill definitions are version-controlled and reviewed at
commit time. The auto-deny means every skill update requires leaving
Claude Code, switching to a terminal, running git pull, switching
back. Multiple times a day per teammate. Friction without added
safety in our setup.

Proposed

"sandbox": {
"filesystem": {
"allowWrite": ["..."],
"allowSkillsWrites": true
}
}

Keep settings.json files hard-deny — those genuinely defend the
boundary.

Version

Claude Code 2.1.131, Linux (WSL2).

Alternative Solutions

I need to pull skills updates every day and tried to find a way to make this possible without potentially exposing the wall of my safe workspace. It's not possible.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

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