Claude Desktop: no permissions.defaultMode or sandbox setting suppresses tool-approval prompts

[pdumler]

Summary

None of the documented permissions.defaultMode values, nor the sandbox.* auto-allow settings, suppress Claude Code's tool-approval prompts inside the Claude Desktop app's interactive chat window. This makes it impossible to run Claude Code hands-off for routine work (edits, reads, git commands, etc.) from the Desktop app, even though the CLI settings say to.

Environment

• Claude Desktop app, Windows 11
• ~/.claude/settings.json (global, applies to all projects)

What was tried, in order, each verified on a brand-new chat (not a resumed one) with the settings file re-validated as correct JSON before testing:

1. permissions.defaultMode: "acceptEdits" — Edit/Write stopped prompting, Bash still prompted.
2. permissions.defaultMode: "auto" — no change from default; still prompted on routine Bash/tool calls.
3. permissions.defaultMode: "bypassPermissions" (with skipDangerousModePermissionPrompt: true) — documented to eliminate tool-permission prompts entirely. Still prompted, confirmed on a freshly-started chat.
4. permissions.defaultMode: "dontAsk" (with skipAutoPermissionPrompt: true) — same result as Claude is either blank or non-interactive #3, still prompted, confirmed on a freshly-started chat.
5. Added sandbox.autoAllowBashIfSandboxed: true and sandbox.allowUnsandboxedCommands: true alongside dontAsk — no change. Confirmed on a freshly-started, newly-named chat with a trivial, entirely read-only command (git status, git log) still producing an "Allow Claude to run ..." dialog.

Example settings.json (sanitized)

{
  "skipAutoPermissionPrompt": true,
  "skipDangerousModePermissionPrompt": true,
  "sandbox": {
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": true
  },
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [ "...a normal allowlist, unrelated to the issue..." ]
  }
}

Expected behavior

Per the documented semantics of bypassPermissions/dontAsk, Claude Code's own prompt layer should not interrupt for routine tool calls.

Actual behavior

Claude Desktop's chat window continues to show a permission-approval dialog for ordinary, safe, read-only commands (e.g. git status, git log) regardless of which of the above modes is set, even on a session started fresh after the setting was applied and verified.

Impact

There appears to be no way, from within ~/.claude/settings.json, to get Claude Desktop's interactive chat surface to stop prompting for routine tool calls — the CLI-documented modes for this behave as if the Desktop app enforces a separate, non-configurable floor. If that's intentional, it isn't discoverable from the settings docs, and it would help to have that documented explicitly (and ideally exposed as a real, working setting) rather than silently ignored.

Additional note

Separately, a plain git/GitHub-credential picker dialog (Windows Credential Manager "Select an account") was also observed interrupting otherwise-unattended git operations when two GitHub identities were cached locally — that one was resolved outside Claude Code (pinning a default credential username), so it's likely unrelated, but mentioning it in case the two are connected in how Desktop handles credential/permission prompting.

[pdumler]

Follow-up: confirmed the underlying engine itself is fine. Running the standalone claude.exe binary directly from a plain terminal (not through Claude Desktop's chat window) with --dangerously-skip-permissions works exactly as documented — a compound git command ran with zero approval prompts.

So this narrows the bug precisely: Claude Desktop's chat-window wrapper does not honor --dangerously-skip-permissions / bypassPermissions / dontAsk / the sandbox auto-allow settings, even though the CLI binary it presumably spawns under the hood respects all of them correctly when invoked directly. Whatever Desktop does differently when launching/hosting the engine for its chat UI is where the floor is coming from.