[BUG] tengu_harbor_permissions feature flag overrides user-configured dangerouslySkipPermissions: true

Users who have explicitly opted into dangerouslySkipPermissions: true are still receiving permission prompts due to server-side feature flags that operate independently of the user's permission configuration.

Specifically, the tengu_harbor_permissions flag (pushed via Statsig and cached in .claude.json) introduces a permission layer that does not respect the user's dangerouslySkipPermissions: true setting. This creates a contradiction: the user has made an explicit, informed choice to bypass permission prompts, but a server-controlled flag overrides that choice without the user's knowledge or consent.

Reproduction

1. Set dangerouslySkipPermissions: true in both ~/.claude/settings.json and ~/.claude/settings.local.json
2. Confirm via claude config or by reading the settings files that bypass mode is active
3. Observe that certain tool calls still trigger permission prompts during normal usage
4. Inspect .claude.json — the Statsig-managed config contains "tengu_harbor_permissions": true
5. This flag is not user-configurable and is pushed server-side

Investigation Findings

Binary analysis of v2.1.109 reveals 7 independent permission sources that can trigger prompts:

| Source | Count in binary | Respects dangerouslySkipPermissions? |
|--------|----------------|---------------------------------------|
| server | 123 refs | Unclear |
| hook | 71 refs | N/A (user-configured, intentional) |
| managed | 44 refs | No (enterprise/policy layer) |
| classifier | 34 refs | No |
| policy | 6 refs | No |
| sandbox | 4 refs | Partially (can be disabled) |
| harbor | 2 refs | No |

The dangerouslySkipPermissions flag only controls one of these layers. The others operate independently, meaning a user who has explicitly opted into bypass mode is still subject to multiple permission systems they cannot disable.

Additionally, tengu_disable_bypass_permissions_mode exists as a Statsig flag (currently false for my account), suggesting Anthropic retains the ability to remotely disable bypass mode entirely — which further undermines user agency over their own configuration.

Additional Context: Project-Level Override Gap

A related issue: project-level .claude/settings.json files that define permissions.allow or permissions.deny blocks — but do NOT include dangerouslySkipPermissions: true — effectively downgrade the user from bypass mode to allow-list mode when working in those project directories. This happens silently with no indication that the global bypass has been overridden.

Expected behavior: Global dangerouslySkipPermissions: true should be inherited by all projects unless a project-level setting explicitly opts out.

Actual behavior: Any project-level permissions block without the bypass flag silently reverts to non-bypass permission checking.

Expected Behavior

If a user sets dangerouslySkipPermissions: true, all client-side permission layers should respect that choice. Server-side flags should not be able to silently override a user's explicit permission configuration.

Proposed Solution

1. dangerouslySkipPermissions should be authoritative — when set to true, it should bypass all client-side permission layers including harbor, classifiers, and policy checks
2. Project-level inheritance — global bypass mode should propagate to project directories unless explicitly overridden at the project level
3. Transparency — if a server-side flag is overriding a user's local configuration, the user should be informed (not silently overridden)

Related Issues

• #9769 — Feature request to make system reminder types individually optional
• #40176 — Task reminder system creates attention bias overriding user direction
• #4464 — System reminder content injection consuming excessive context tokens
• #17601 — Hidden system-reminder injections consuming 15%+ of context window

Environment

• Claude Code v2.1.109
• Platform: WSL2 (Ubuntu on Windows)
• Shell: zsh
• Permission mode: dangerouslySkipPermissions: true in both settings.json and settings.local.json