Project-level settings.local.json sandbox config ignored in Desktop-app (claude-desktop entrypoint) sessions

Summary
A sandbox configuration block placed in a project-scoped .claude/settings.local.json is not applied when the session is started via the Claude Desktop app (CLAUDE_CODE_ENTRYPOINT=claude-desktop), even though the exact same configuration is correctly enforced when the session is started directly in a terminal (CLAUDE_CODE_ENTRYPOINT=cli).

Steps to reproduce

1. In a Claude Desktop-connected session for a given project directory, create .claude/settings.local.json in that exact project directory (the file did not previously exist) with:

{
  "sandbox": {
    "enabled": true,
    "filesystem": { "denyRead": ["/mnt/c"] }
  }
}

1. In the same Desktop-app session, run: cat /mnt/c/test.txt (or any file under /mnt/c).
2. Separately, verify the identical block placed in ~/.claude/settings.json (user-level) does enforce the restriction in the same session.

Expected
The read is denied, since the session is working in the project directory that owns this settings.local.json.

Actual

• Terminal session (cli entrypoint), identical config placed in the project-scoped settings.local.json: read is blocked, as expected.
• Desktop-app session (claude-desktop entrypoint): read succeeds - file content is returned normally. Only moving the identical block to the user-level ~/.claude/settings.json makes it enforce correctly in the Desktop-app session.

Environment

• Platform: WSL2 (Ubuntu), Linux 6.18.33.2-microsoft-standard-WSL2
• bwrap (bubblewrap) 0.11.1-1ubuntu0.1, socat 1.8.1.1-1ubuntu0.1 - confirmed both function correctly when invoked directly (manual bwrap --unshare-net test correctly blocked network access)
• Claude Code reached via Desktop app bridge (CLAUDE_CODE_EXECPATH=.../remote/ccd-cli/2.1.237)

Why this matters
Users may reasonably expect a project-committed settings.local.json sandbox policy to apply uniformly regardless of how they access the same project (terminal vs. Desktop app). Silently skipping it for Desktop-app sessions could lead to a false sense of security, e.g. in a compliance/data-protection context.