bypassPermissions mode silently downgrades to acceptEdits after approving a suspicious path prompt

Root Cause Analysis (source-level)

_Traced through the published source and verified independently via Codex review._

The bug is a missing permission-mode guard in BashTool/pathValidation.ts and PowerShellTool/pathValidation.ts that unconditionally downgrades the permission mode to acceptEdits when a safety-check prompt is approved.

---

The bug: unconditional setMode: 'acceptEdits' in suggestions

File: src/tools/BashTool/pathValidation.ts (lines 769–776)

// For write operations, also suggest enabling accept-edits mode
if (operationType === 'write' || operationType === 'create') {
  suggestions.push({
    type: 'setMode',
    mode: 'acceptEdits',    // ← NO check for current mode
    destination: 'session',
  })
}

When a Bash command triggers a safety-check permission prompt (suspicious path pattern, protected file, etc.), this code unconditionally adds setMode: 'acceptEdits' to the suggestion list — regardless of the current permission mode.

The same bug exists in three locations:

1. src/tools/BashTool/pathValidation.ts:770 — Bash write/create operations
2. src/tools/PowerShellTool/pathValidation.ts:1792 — PowerShell write/create (first site)
3. src/tools/PowerShellTool/pathValidation.ts:1905 — PowerShell write/create (second site)

The approval flow that triggers the downgrade

When the user approves a safety-check prompt via "Yes, and always allow..." (yes-apply-suggestions):

1. BashPermissionRequest.tsx (line ~399) passes permissionResult.suggestions directly to onAllow()
2. interactiveHandler.ts (line ~154) forwards the suggestions unchanged
3. PermissionUpdate.ts (line 55) applies setMode by direct assignment — no downgrade check:

``typescript
case 'setMode':
return { ...context, mode: update.mode } // Unconditional
``

1. Result: bypassPermissions → acceptEdits

Why safety checks fire in bypassPermissions mode

This is correct behavior — permissions.ts step 1g (line 1257–1264) makes safety checks bypass-immune:

// 1g. Safety checks are bypass-immune — they must prompt even in bypassPermissions mode.
if (toolPermissionResult?.behavior === 'ask' &&
    toolPermissionResult.decisionReason?.type === 'safetyCheck') {
  return toolPermissionResult
}

The prompt should appear (correct), but approving it should NOT downgrade the permission mode (bug).

The fix already exists — in a different file

src/utils/permissions/filesystem.ts (lines 1439–1446) has exactly the guard that BashTool and PowerShellTool are missing:

// Only suggest setMode:acceptEdits when it would be an upgrade. In auto
// mode the classifier already auto-approves edits; in bypassPermissions
// everything is allowed; in acceptEdits it's a no-op.
const shouldSuggestAcceptEdits =
  toolPermissionContext.mode === 'default' ||
  toolPermissionContext.mode === 'plan'

The file-edit path correctly only suggests acceptEdits when the current mode is 'default' or 'plan' (where it's an upgrade). The Bash/PowerShell paths are missing this same guard.

---

Suggested Fix

Add the shouldSuggestAcceptEdits guard to all three affected sites:

// Add this check before the setMode push — matches filesystem.ts pattern
const shouldSuggestAcceptEdits =
  toolPermissionContext.mode === 'default' ||
  toolPermissionContext.mode === 'plan'

if (shouldSuggestAcceptEdits && (operationType === 'write' || operationType === 'create')) {
  suggestions.push({
    type: 'setMode',
    mode: 'acceptEdits',
    destination: 'session',
  })
}

Apply at:

1. src/tools/BashTool/pathValidation.ts:770
2. src/tools/PowerShellTool/pathValidation.ts:1792
3. src/tools/PowerShellTool/pathValidation.ts:1905

A centralized downgrade guard in applyPermissionUpdate() was considered but rejected — that function is used for legitimate downward transitions (e.g., ExitPlanMode → default, permissionSetup → default), so a blanket block would break real flows.

---

Immediate Workaround

After the mode downgrades, press Shift+Tab to cycle back through permission modes to bypassPermissions.

---

Related Issues

• #41758 — Plan mode fails to restrict write tools when bypass is available (same permission system, different bug)
• #32934 — ExitPlanMode fails with --dangerously-skip-permissions

_Analysis based on source code, verified by independent Codex review._

Additional reproduction data from Windows 11 Desktop app (Claude Opus 4.6, 1M context):

5 occurrences in a single 3-hour session. Trigger confirmed: any Write/Edit tool call targeting paths outside the project root (e.g., ~/.claude/memory/, C:\BugTracker\) causes bypass mode to silently downgrade to acceptEdits. Parallel Agent (Explore) calls reading across multiple directory trees also triggered it.

git push alone (without prior out-of-project writes) did NOT trigger it. Bash echo to /tmp triggered a sandbox prompt but did NOT downgrade the mode — different mechanism.

This matches the 'suspicious path pattern' trigger described in this issue.

This was fixed in v2.1.97 — Approving a suspicious-path prompt no longer silently downgrades bypassPermissions or auto mode to acceptEdits. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.