Desktop: Edit/Write/Agent instantly denied (~18-25 ms) even in bypassPermissions mode; grant state resets mid-session (v2.1.197, Windows)

Summary

On Claude Code Desktop for Windows (harness version 2.1.197 per transcript version field), Edit/Write/Agent tool calls are intermittently denied with a bare "Permission to use Edit has been denied" even though:

• the session permission mode is bypassPermissions (74% of observed denials; rest in acceptEdits and auto),
• user-level ~/.claude/settings.json contains bare Edit, Write, Agent in permissions.allow,
• no deny rule, hook, or managed policy matches these tools (verified: no PreToolUse hook for Edit/Write, no managed-settings.json, no HKLM policy),
• the target files are inside the session's own git worktree (and in some cases the session scratchpad temp directory).

Evidence

• 222 denial events across 72 transcripts in 21 days (2026-06-08 → 2026-07-02), 10-30/day, no downward trend.
• Denial latency measured from tool_use timestamp to denial event: ~18-25 ms — too fast for the LLM auto-mode classifier or a user prompt timeout → looks like a local client-side gate running above the permission-mode system.
• Mode × tool distribution: bypassPermissions/Edit 118, bypassPermissions/Write 29, bypassPermissions/Agent 14, acceptEdits/Edit 12, auto/Edit 10, plus subagent collateral.
• Same-session flapping: one session had 118 successful Edit calls and 5 denials interleaved → grant state appears to reset mid-session and later recover.
• Example: transcript fe847a0d-65e0-4f01-bf48-55aa55bc91fd (project ...worktrees-clever-allen-a186fd), 2026-07-02T05:29:03.466Z tool_use → denied .484Z (18 ms), mode bypassPermissions, target tests/e2e/faq.spec.ts inside the worktree.
• Entrypoint of all denials: claude-desktop. GrowthBook flags active: tengu_auto_mode_config (twoStageClassifier), tengu_harbor_permissions, tengu_permission_friction.

What it is not

• Not settings corruption (all JSON layers valid), not deny rules, not hooks, not managed policy.
• Not the documented auto-mode classifier behavior (#57735) — that one explains auto mode denials, but not instant denials in bypassPermissions.
• Not per-worktree approval loss (#13019) — allowedTools entries are empty everywhere; this is a runtime gate, not a config lookup.

Environment

• Windows Server 2022, Claude Code Desktop (harness 2.1.197 in transcripts; stale native CLI 2.1.158 also installed but unused by Desktop sessions)
• Heavy git-worktree workflow: 5-10 parallel sessions/day, ~250 active worktrees, ~1080 project entries in ~/.claude.json

Ask

1. What component denies a tool call in bypassPermissions mode within ~20 ms, and under which conditions does its state reset mid-session?
2. If this is the Desktop-side permission bridge (harbor), can denial reasons (added in 2.1.193 for auto mode) also be surfaced for these denials? A bare "has been denied" is undiagnosable.