[FEATURE] Desktop local sessions: scoped permission profile, and an explained rather than hidden sandbox row on Windows (successor to #81121)

Successor to #81121 (Desktop local sessions: user-facing scoped sandbox and approval controls). Lifecycle automation closed it on 2026-09-17 with "Please open a new issue if this is still relevant". It is still relevant.

This replacement is narrower than #81121. The enforcement layer for native Windows now has its own open owner, #79300 (Native Windows: working directory does not scope shell-tool filesystem access). A maintainer routed the parallel report #79301 there, and #69495 asks for a specific Windows sandboxing mechanism. This issue covers only what the Desktop app shows and lets the user configure.

Problem

Claude Desktop's Code tab offers Manual, Accept edits, Plan, Auto, and Bypass permissions. None of them lets a user say "work freely inside this project, and ask before leaving it or causing an external side effect".

Some of this has shipped since #81121 was filed:

• Desktop's Settings → Claude Code now has a Local sandbox row ("Runs commands from Claude Code in an isolated sandbox. Applies to new sessions.") and a dependent Strict sandbox mode row. Both are read from the settings chunk app/resources/ion-dist/assets/v1/c71860c77-mTuuna2U.js in 2.7032.0.0.
• permissions.blockReadsOutsideWorkingDirectories makes the file tools refuse reads outside the working directories. It is JSON-only.

The rest of the boundary is still JSON-only: permissions.allow / ask / deny, and sandbox.filesystem / sandbox.network. /permissions replies that it isn't available in this environment, per What's not available in Desktop. The earlier request to expose /sandbox in Desktop, #71152, and the broader Windows Desktop report #76886 were both closed by lifecycle automation in September.

On native Windows, the new sandbox row is hidden rather than explained. The component returns nothing when the platform is win32 (if(!E?.setLocalSandboxEnabled||t)return null, with t = platform === "win32"). That is consistent with the sandbox documentation ("Native Windows is not supported"). The result is that a Windows user sees no sandbox setting at all, and nothing tells them that the project folder does not limit what shell commands can reach (#79300).

Requested

1. A scoped profile in the Desktop mode selector. It auto-allows reads and edits inside the session folder, and asks before:

• paths outside the folder,
• the first network request to a new domain,
• external side effects such as git push, creating issues, PRs or comments, publishing, and deploying.

Offer once / session / project choices on each prompt.

1. A plain-language view of the effective policy, with an editor for the underlying allow / ask / deny and sandbox rules, so users don't have to author hidden JSON.
2. On native Windows, until #79300 is resolved, show the Local sandbox row disabled instead of hiding it. It should explain that the project folder is not an enforced boundary for shell commands there, and point to a WSL session as the sandboxed alternative.

Items 1 and 2 are useful on every platform. Item 3 is the Windows-specific minimum.

Environment

• Windows 11, Claude Desktop 2.7032.0.0 (MSIX), bundled Claude Code
• Checked on 2026-09-23 against the Desktop and sandboxing documentation pages, the Desktop changelog through 2.7032.0, and the shipped settings bundle