[BUG] Desktop app: GrowthBook tengu_quill_harbor silently overrides "Allow bypass permissions" setting and permissions.defaultMode

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Desktop app: GrowthBook tengu_quill_harbor silently overrides "Allow bypass permissions" setting and permissions.defaultMode

Environment

• Claude Desktop on macOS (Darwin 25.3.0)
• ~/.claude/settings.json contains "permissions": { "defaultMode": "bypassPermissions" } and "skipDangerousModePermissionPrompt": true
• Settings → "Allow bypass permissions mode" toggled on
• CLI claude --dangerously-skip-permissions works correctly on the same machine

Behavior

1. Every new session launches in Accept Edits, with the banner: "Bypass Permissions mode isn't enabled. The session started in Accept Edits — enable Bypass

Permissions in Settings to use it."

1. Switching modes from inside the session fails with "Permission mode couldn't be changed."
2. Manually editing ~/.claude.json to set tengu_quill_harbor and cachedGrowthBookFeatures.tengu_quill_harbor to "bypassPermissions" does not survive: as soon as a

new session starts, both fields flip back to "acceptEdits". The override appears to refetch (or re-mirror from the GrowthBook cache) on session creation, not just
app launch.

Subprocess-level evidence (~/Library/Logs/Claude/main.log)
[CCD] Failed to set permission mode for session local_<uuid>:
Cannot set permission mode to bypassPermissions because the session
was not launched with --dangerously-skip-permissions
at .../app.asar/.vite/build/index.js:462:6165
This confirms the subprocess is spawned without --dangerously-skip-permissions and the launch flag is immutable for the session's lifetime — so runtime mode changes
can't recover from the wrong initial value.

Root cause

• Server-side experiment assigns tengu_quill_harbor = "acceptEdits" on this account.
• The desktop launcher uses tengu_quill_harbor (cached in ~/.claude.json under cachedGrowthBookFeatures and mirrored to a top-level key) to decide whether to pass

--dangerously-skip-permissions to the Claude Code subprocess.

• Neither the Settings toggle nor permissions.defaultMode in ~/.claude/settings.json overrides this experiment value. Related flags on the account are consistent

with bypass mode being allowed (tengu_disable_bypass_permissions_mode: false, tengu_harbor_permissions: true, tengu_permission_friction: true) — so this isn't a
policy block, it's just the experiment forcibly defaulting bypass off with no user-facing escape hatch.

UX problem
The Settings toggle and local defaultMode value are silently overridden by a server-side experiment with no indication an experiment is in control. From the user's
perspective the setting is enabled but does nothing. At minimum the toggle should either:

• (a) actually override the experiment for users who explicitly opt in, or
• (b) be disabled with a visible "managed by your account configuration" message and a link to context.

Workaround
Use claude --dangerously-skip-permissions from the CLI. The Desktop app is unusable for bypass-mode workflows until either the local override path is fixed or this
account exits the experiment.

Suggested fix
Treat an explicit user setting (Settings toggle or permissions.defaultMode in ~/.claude/settings.json) as authoritative over the GrowthBook assignment for
tengu_quill_harbor, and pass --dangerously-skip-permissions to the subprocess accordingly.

What Should Happen?

I should be able to choose Bypass Permissions. I've already got it set as the default, and it defaults to it but then reverts to accept edits. Once I'm in a conversation, it will not allow me to set Bypass Permissions, whatever I do, even if I quit the app and reopen. Start new session, Bypass Permissions is just not available to me in the Claude desktop anymore.

Error Messages/Logs

Steps to Reproduce

Title: Desktop app: GrowthBook tengu_quill_harbor silently overrides "Allow bypass permissions" setting and permissions.defaultMode

Environment

• Claude Desktop on macOS (Darwin 25.3.0)
• ~/.claude/settings.json contains "permissions": { "defaultMode": "bypassPermissions" } and "skipDangerousModePermissionPrompt": true
• Settings → "Allow bypass permissions mode" toggled on
• CLI claude --dangerously-skip-permissions works correctly on the same machine

Behavior

1. Every new session launches in Accept Edits, with the banner: "Bypass Permissions mode isn't enabled. The session started in Accept Edits — enable Bypass

Permissions in Settings to use it."

1. Switching modes from inside the session fails with "Permission mode couldn't be changed."
2. Manually editing ~/.claude.json to set tengu_quill_harbor and cachedGrowthBookFeatures.tengu_quill_harbor to "bypassPermissions" does not survive: as soon as a

new session starts, both fields flip back to "acceptEdits". The override appears to refetch (or re-mirror from the GrowthBook cache) on session creation, not just
app launch.

Subprocess-level evidence (~/Library/Logs/Claude/main.log)
[CCD] Failed to set permission mode for session local_<uuid>:
Cannot set permission mode to bypassPermissions because the session
was not launched with --dangerously-skip-permissions
at .../app.asar/.vite/build/index.js:462:6165
This confirms the subprocess is spawned without --dangerously-skip-permissions and the launch flag is immutable for the session's lifetime — so runtime mode changes
can't recover from the wrong initial value.

Root cause

• Server-side experiment assigns tengu_quill_harbor = "acceptEdits" on this account.
• The desktop launcher uses tengu_quill_harbor (cached in ~/.claude.json under cachedGrowthBookFeatures and mirrored to a top-level key) to decide whether to pass

--dangerously-skip-permissions to the Claude Code subprocess.

• Neither the Settings toggle nor permissions.defaultMode in ~/.claude/settings.json overrides this experiment value. Related flags on the account are consistent

with bypass mode being allowed (tengu_disable_bypass_permissions_mode: false, tengu_harbor_permissions: true, tengu_permission_friction: true) — so this isn't a
policy block, it's just the experiment forcibly defaulting bypass off with no user-facing escape hatch.

UX problem
The Settings toggle and local defaultMode value are silently overridden by a server-side experiment with no indication an experiment is in control. From the user's
perspective the setting is enabled but does nothing. At minimum the toggle should either:

• (a) actually override the experiment for users who explicitly opt in, or
• (b) be disabled with a visible "managed by your account configuration" message and a link to context.

Workaround
Use claude --dangerously-skip-permissions from the CLI. The Desktop app is unusable for bypass-mode workflows until either the local override path is fixed or this
account exits the experiment.

Suggested fix
Treat an explicit user setting (Settings toggle or permissions.defaultMode in ~/.claude/settings.json) as authoritative over the GrowthBook assignment for
tengu_quill_harbor, and pass --dangerously-skip-permissions to the subprocess accordingly.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.152 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_