[FEATURE] Workspace boundary enforcement for local file writes — auto mode allows out-of-workspace Bash writes silently; recommended alternative (sandbox) unavailable on native Windows

Summary

Follow-up to #63477, which was closed as stale/not planned. I'm re-filing because the core rationale for closing — "use the sandbox for hard boundary enforcement" — does not hold on native Windows, and the affected user base has since expanded to non-developers via the Claude desktop app.

What happened

What happened to me: I was working in a designated project folder with auto mode enabled. Mid-session, the agent announced that it would copy a file into C:\Users\<me>\Downloads and immediately executed the cp command without asking for permission. I had asked only for a complete path or a usable link; I had not authorized creating a file in Downloads.

Nothing destructive happened, but that is exactly the concern: because the auto-mode classifier is risk-based rather than boundary-based, a benign and reversible local write outside the workspace can be approved automatically.

Why this deserves reconsideration

1. Least astonishment is violated silently. Designating a project folder creates an implicit contract: the agent operates in this folder. Auto mode doesn't honor that contract for Bash, and nothing at auto-mode opt-in discloses it. Even a one-line disclosure ("local writes outside your workspace are not treated as risky and may run without prompting") would have prevented the trust damage.

1. The user base changed; the threat model didn't. The risk-based model assumes a developer who understands their machine. Claude Code now ships inside the Claude desktop app to a general audience — office workers, writers, non-developers. For them, "the AI wrote files into my personal folders on its own" is not an acceptable edge case of a risk model.

1. The official alternative doesn't exist where it's needed most. The documented answer for hard boundary enforcement is the Bash sandbox — but per the docs, "Native Windows is not supported." Windows is where the largest share of non-developer desktop-app users live. "We won't do boundary enforcement at the permission layer, use the sandbox" is not an available answer on the platform with the most at-risk users. This is why I believe the stale closure of #63477 shouldn't stand.

1. Workarounds are expert-only. Layering permissions.deny (Write/Edit only — doesn't cover Bash), custom autoMode.soft_deny prose rules, and CLAUDE.md instructions works — I've done all three. But none are defaults, none are discoverable to a non-developer, and none are hard guarantees. A safety property that requires reading engineering blog posts to know you need it is not a safety property for a mass-market product.

Proposed solutions (ascending effort — any would help)

1. Disclose the behavior at auto-mode opt-in.
2. Ship a workspace-boundary soft_deny rule in the classifier defaults (out-of-workspace local writes require explicit user intent), instead of requiring users to author it themselves.
3. An opt-in workspaceBoundary permission setting as proposed in #63477 — at minimum on platforms where the sandbox is unavailable.

Postscript — a live demonstration

While filing this very issue via gh CLI (with my explicit approval in chat), the auto-mode classifier blocked the submission as a potentially unsafe external action. So the same system that silently allowed an unprompted write into my personal Downloads folder required intervention to perform an action I explicitly requested. The asymmetry is exactly the problem: the classifier protects Anthropic's threat model (outbound publication), not the user's (workspace boundary).

Environment

• Platform: native Windows 11 (Claude desktop app)
• Permission mode: auto (permissions.defaultMode: "auto")
• Sandbox: unavailable (native Windows unsupported per docs)