Permission prompts never fire in desktop-app session; mode silently reverts to acceptEdits each turn

Summary

In a Claude Code desktop app session (Code tab, Agent SDK-hosted), no permission prompt is shown for any action, and the session's permission mode silently reverts to acceptEdits at user-turn boundaries after being explicitly set to default.

Net effect: a user who selects Manual mode gets no gating at all, with no indication that anything is wrong.

Environment

• Claude Code 2.1.271 (from the running process path .../claude-code/2.1.271/claude.app/...)
• macOS, Darwin 25.2.0
• Claude desktop app, Code tab. Session is local (not remote) and attended.
• Permission mode as reported by the session: alternates between default and acceptEdits (see below)

Steps / observations

1. Session started in default (confirmed by reading the session's own metadata). An Edit to a scratch file matching no allow rule completed with no prompt.
2. Bash commands matching no allow rule (printf '...' > file, rm -f file) also completed with no prompt.
3. The session transcript (~/.claude/projects/<slug>/<session-uuid>.jsonl) records "permissionMode":"default" on the first user message and "permissionMode":"acceptEdits" on the second. No mode-switch tool was called in between, and no approval card was shown.
4. Setting the mode back to default mid-turn succeeds and is confirmed by a follow-up read of the session metadata — but by the next user turn the mode is acceptEdits again. Repeated twice.
5. With the mode confirmed as default immediately before and after, an Edit to a non-matching path still completed with no prompt.
6. Escalating default -> acceptEdits — documented to show an approval card in every permission mode and wait for it — completed instantly with no card.

Expected

• In default mode, an Edit or Bash call matching no allow rule prompts for approval.
• An escalation to a broader permission mode shows an approval card and waits.
• A permission mode set explicitly persists across turns until changed.

Ruled out

• Not sandboxing. No sandbox key in user, project, or project-local settings (the managed-settings file does not exist); no sandbox-exec anywhere in the process ancestry (zsh <- claude <- disclaimer <- Claude.app); no isSandboxed field recorded on any tool call in the transcript.
• Not an over-broad allow rule. No broad Edit/Write allow and no permissions.defaultMode in any settings layer. The allow rules present are all path-specific and none matches the probe path.
• Not a competing deny/ask rule, and no hooks granting allows.

Possibly related

A Bash write to a path outside the session's working directories caused that directory to be added automatically to the session's additional working directories, with no prompt. That may be intended, but it also removes a natural boundary and made it harder to construct a valid negative control.