[BUG] bypassPermissions mode silently downgrades to acceptEdits mid-session via Statsig gate

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?

Sessions configured with defaultMode: "bypassPermissions" intermittently drop to acceptEdits mode mid-session without user action. The mode change is triggered by an async
Statsig feature flag check (tengu_disable_bypass_permissions_mode) that runs after session start, silently overriding the user's configured permission mode.

The internal code path: checkAndDisableBypassPermissions calls shouldDisableBypassPermissions() which evaluates pR6("tengu_disable_bypass_permissions_mode"). When the gate
returns true, the session's bypass mode is revoked.

What Should Happen?

If a user has explicitly configured defaultMode: "bypassPermissions" in settings.json and skipDangerousModePermissionPrompt: true, the session should remain in bypass mode
for its duration. If a server-side gate is going to override user settings, the user should be notified visibly (not just a warn-level log), and ideally given the option to
acknowledge and continue.

Error Messages/Logs

No visible error shown to the user. The internal log message (visible only with --debug) is:
  bypassPermissions mode is being disabled by Statsig gate (async check)

Steps to Reproduce

1. Configure ~/.claude/settings.json:

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

1. Start a claude session — it begins in Bypass mode as expected
2. Use the session normally for 5–70 minutes
3. At some point the status line changes from "Bypass" to "Accept" without any user action
4. The session is now in acceptEdits mode, prompting for permissions on tool calls that bypass mode would have auto-approved

The timing is inconsistent (observed 5 min to 72 min delays across sessions), consistent with an async feature flag evaluation.

Evidence from session logs showing permissionMode field on user messages flipping mid-session (same sessionId throughout):
2026-04-05T21:15:48Z bypassPermissions "ive removed 88.218..."
2026-04-05T22:27:49Z acceptEdits "create a 1pass entry..."
2026-04-05T22:32:12Z bypassPermissions "r2 account token uuid..."

This pattern reproduced across 4 separate sessions in 2 different project directories.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.85

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

The relevant code paths in the bundled JS (from strings on the binary):

• shouldDisableBypassPermissions → pR6("tengu_disable_bypass_permissions_mode") (Statsig gate)
• isBypassPermissionsModeDisabled → checks both the Statsig gate and settings.permissions.disableBypassPermissionsMode
• checkAndDisableBypassPermissions → async function that disables bypass mid-session when the gate fires
• initialPermissionModeFromCLI → at startup, if bypass is disabled, falls through the candidate list and lands on default; but mid-session the transition goes to acceptEdits

Session end reasons include "bypass_permissions_disabled" confirming this is a known internal code path.

The disableBypassPermissionsMode settings key exists for org/MDM policy use, but in this case the gate is firing without any such setting — it's purely server-side.