claude-code - 💡(How to fix) Fix [FEATURE] Allow user override of sandbox auto-deny on .claude/skills/ (currently hard-coded in 2.1.x) [1 pull requests]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Fix Action

Fixed

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • 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

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING