[FEATURE] Desktop local sessions: user-facing scoped sandbox and approval controls

### Preflight Checklist

* [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this Desktop-specific feature has not been requested in an open issue
* [x] This is a single feature request (not multiple features)

### Problem Statement

Claude Desktop local Code sessions expose coarse permission modes, but no user-facing way to define the safety boundary many developers actually want: work autonomously inside the selected project, while asking before crossing that boundary or causing an external side effect.

The current choices create an avoidable tradeoff:

* Manual produces frequent approval prompts.
* Accept edits reduces edit prompts, but does not provide a visible, comprehensive policy for network access, external side effects, or shell-tool filesystem scope.
* Auto removes routine prompts and relies on a classifier.
* Bypass permissions removes nearly all prompts.

Claude Code supports `permissions.allow`, `permissions.ask`, `permissions.deny`, hooks, and `sandbox` settings in JSON. However, these controls are not discoverable or configurable in the Desktop UI. Command-pattern rules are also brittle for free-form shell commands and cannot replace OS-level filesystem and network isolation.

This gap is especially serious on native Windows. The official sandbox currently supports macOS, Linux, and WSL2, but not native Windows. As documented in #79301, choosing a project directory does not constrain PowerShell or Bash filesystem access: shell commands can still reach any path available to the Windows user.

The result is user-unfriendly in both directions. Users either approve many low-risk actions manually, or enable broader autonomy that can include writes outside the intended project, network access, `git push`, GitHub issue or PR comments, releases, deployments, and other externally visible actions.

### Proposed Solution

Add a user-facing **Scoped autonomy** permission profile for local Claude Desktop Code sessions, backed by enforced sandbox and permission rules.

The profile should let users configure these boundaries before starting a session and adjust them during the session:

* Auto-allow reads and file edits inside the selected project directory.
* Ask before reading or writing outside the project directory, with clear once/session/project choices.
* Ask before the first outbound network request, with optional per-domain once/session/project grants.
* Ask before external side effects such as `git push`, creating or editing GitHub issues and PRs, posting public comments, publishing releases, or deploying.
* Keep protected locations and destructive commands behind an explicit approval regardless of the general mode.
* Show the effective policy in plain language in the Desktop UI, with an advanced editor for the underlying `allow`/`ask`/`deny` and sandbox rules.

The boundary should be enforced by the harness or operating system, not only by model instructions or command-string matching. Native Windows should receive a real scoped sandbox using Windows isolation primitives. Until that exists, Desktop should prominently explain that the project directory is not a hard shell boundary and offer an easy WSL2-backed local-session option.

This would complement the existing permission modes rather than replace them: Manual, Accept edits, Auto, and Bypass permissions describe general autonomy, while the scoped policy defines where that autonomy stops.

### Alternative Solutions

Current workarounds are insufficient:

* Hand-edit `~/.claude/settings.json` with `permissions.ask` and `permissions.deny` rules. This is not discoverable in Desktop and requires knowing the permission DSL.
* Configure `sandbox.filesystem` and `sandbox.network` manually. Desktop does not expose `/sandbox`; #71152 tracks that missing UI. Native Windows is not supported by the sandbox.
* Use hooks or wrapper scripts. These add substantial setup and still depend on parsing arbitrary commands correctly.
* Use Manual mode. This preserves oversight but causes approval fatigue and blocks unattended progress.
* Use Auto mode. Explicit `ask` rules can still prompt, but users need to know and author them outside the Desktop UI, and native Windows still lacks OS-level enforcement.

### Priority

High - Significant impact on productivity

### Feature Category

Configuration and settings

### Use Case Example

A developer selects `C:\projects\my-app` in Claude Desktop and asks Claude to implement and test a change.

With Scoped autonomy:

1. Claude can read, create, and edit files under `C:\projects\my-app` without interruption.
2. It can run local build and test commands inside the project.
3. A package download or other network request pauses with a domain-specific approval.
4. An attempt to access `C:\Users\name\Documents`, a sibling repository, a mapped drive, or a UNC share pauses with the exact path and requested operation.
5. `git push`, `gh issue comment`, `gh pr create`, publishing, and deployment pause as external side effects even though ordinary local work remains autonomous.

This provides useful unattended progress without granting ambient access to the entire user account and its external credentials.

### Additional Context

Related issues:

* #48097 proposed named permission presets, including a permissive mode that prompts only for network access and operations outside the working directory. It was closed and locked by the stale bot, which requested a new issue if still relevant.
* #26345 proposed mid-granularity live permission controls and was also closed by the stale bot.
* #35527 proposed granular permission profiles as an alternative to the binary skip-permissions choice and was also closed by the stale bot.
* #71152 is the active request to expose `/sandbox` and sandbox network configuration in Claude Desktop.
* #79301 documents that native Windows shell tools are not constrained to the working directory.
* #76886 describes the broader Windows Desktop discoverability and sandboxing problem.

Official documentation:

* Desktop permission modes: https://code.claude.com/docs/en/desktop#choose-a-permission-mode
* Permission rules: https://code.claude.com/docs/en/permissions
* Sandbox configuration and platform support: https://code.claude.com/docs/en/sandboxing

Codex Desktop provides the relevant UX precedent: it can allow ordinary workspace edits while requesting approval when a command needs network access or attempts to write outside the workspace. Claude Desktop should offer an equally understandable boundary without requiring users to author hidden JSON policies.

Start with the linked Desktop permission, permissions, and sandboxing documentation, then review issues #71152 and #79301 to understand existing sandbox and Windows limitations. Define the policy and enforcement boundaries before implementation; done means Desktop exposes scoped controls with clear approvals and enforced filesystem, network, and external-side-effect limits.

Written by the indexing model from the issue text.