Permission mode reverts from bypassPermissions to acceptEdits on first prompt (Claude Desktop 2.1.149 / Cowork, macOS)

Description

In Claude Desktop (FleetView) on macOS with Cowork enabled, the permission mode silently reverts from bypassPermissions to acceptEdits on the very first user prompt of a session — despite all three opt-ins being present:

• ~/.claude/settings.json: permissions.defaultMode = "bypassPermissions" + skipDangerousModePermissionPrompt: true
• claude_desktop_config.json epitaxy prefs: folder /Users/<me>/work/<project> set to bypassPermissions, with the ack token present
• bypassPermissionsOptInByAccount and bypassPermissionsGateByAccount both true

The UI briefly shows the "Bypass permissions" badge at session start, but the actual session state never enters bypass — the JSONL log shows permissionMode: acceptEdits from the very first user message onward.

Trying to toggle to bypass through the UI returns: "Permission mode couldn't be changed. You can try again."

Steps to reproduce

1. macOS, Claude Desktop 2.1.149, Cowork enabled
2. Configure folder for bypassPermissions (UI or epitaxy prefs)
3. Set ~/.claude/settings.json:

``json
{
"permissions": { "defaultMode": "bypassPermissions" },
"skipDangerousModePermissionPrompt": true
}
``

1. Open a new session in that folder — UI shows yellow "Bypass" badge
2. Send any prompt
3. Observe: badge persists or flips to "Edit automatically"; tool calls prompt for permission
4. Try toggling mode via UI → "Permission mode couldn't be changed" warning

JSONL evidence

From ~/.claude/projects/<sanitized-cwd>/<session>.jsonl — current session (138 messages):

| permissionMode | count |
|---|---|
| acceptEdits | 8 user messages |
| bypassPermissions | 0 |

<task-notification> entries: 3 (none carry permissionMode, but they're interleaved with user messages that all carry acceptEdits).

First user message at line 3 already has permissionMode: acceptEdits — bypass is never written to the session.

Related issues

• #36473 — same symptom (Windows, CLI), closed stale
• #39057 — same symptom (macOS, VSCode), closed stale; comment by @AlexSostin identified run_in_background task-notification snapshot as one trigger
• #36819 — subagent mode: frontmatter contamination (second trigger)
• #55558 — auto mode not inherited in new sessions
• #59398 — "Permission mode couldn't be changed" persisting (Max plan)
• #60724 — same error on desktop app (AUTO mode)

This issue is the Cowork-specific manifestation that none of the above cover. The Cowork harness appears to inject background activity (CCD session-mgmt, status checks, etc.) at session start, and per @AlexSostin's hypothesis the task-notification frame restores a stale acceptEdits before the user's first turn even runs — which explains why bypass is never observed in the JSONL at all.

Workarounds attempted (none fully work)

• defaultMode: bypassPermissions in user settings.json → mode still resets
• skipDangerousModePermissionPrompt: true → no effect on the underlying reset
• Folder-level epitaxy bypassPermissions ack → UI shows badge but state doesn't follow
• Toggling via UI mid-session → "Permission mode couldn't be changed" warning

Environment

• OS: macOS (Darwin)
• App: Claude Desktop (FleetView) 2.1.149
• Cowork: enabled (cowork-enabled-cli-ops.json present, CCD MCP servers active)
• Plan: Pro
• Session entrypoint: claude-desktop (interactive)

Impact

bypassPermissions is effectively unusable in Cowork on the desktop app — every tool call prompts despite the configured opt-in, breaking autonomous workflows (skills, /loop, agent runs).