Intermittent reasonless permission denial on Edit/Write (fail-closed), persists under bypassPermissions

Summary

Edit and Write tool calls are intermittently denied with a bare, reasonless message — Permission to use Edit has been denied. / Permission to use Write has been denied. — with no explanation string. It happens even with bypassPermissions mode enabled, where no denial should occur. Bash (including Bash-based file writes via > / python) is unaffected during the same window, and an immediate retry of the same Edit/Write usually succeeds.

Environment

• Claude Code 2.1.195
• macOS (Darwin 25.5.0)
• Permission mode: bypassPermissions (also observed in auto mode)

Symptom

• Tool result is literally Permission to use Edit has been denied. (no reason), same for Write.
• Intermittent: many Edit/Write calls succeed; then a stretch fails; then they succeed again — within one session.
• Content-independent: the exact same file content that was denied succeeds on retry minutes later (verified with both a trivial hello world write and a longer markdown edit).
• Tool-specific: Bash and Bash-based file writes are never affected during the same window.
• Persists under bypassPermissions, which by definition should allow all tool calls without prompting or denial.

Ruled out (it is not user config)

• No permissions.deny rule matches Edit/Write in any settings layer (user / project / project-local / worktree).
• The only PreToolUse hooks registered on Edit|Write (from enabled plugins) fail open for the affected file types (e.g. .md / .txt) — they return allow, not block.
• Reproduced with trivial and non-trivial content; same content denied then allowed. So it is neither a deny-rule, a hook, nor content-based.

Expected

1. bypassPermissions should never deny a tool call.
2. Any denial should carry a reason. A fail-closed internal check (e.g. the permission/classification evaluation path erroring or timing out) should not surface as a reasonless deny — it should fail open under bypass, or at minimum report the underlying error so users can tell a transient failure from a real config block.

Impact

The reasonless message makes a transient failure look like a misconfiguration, sending users to edit settings.json (which can't fix it, since it isn't config). Workarounds are manual retries or routing file writes through Bash.

Likely cause

The permission/classifier evaluation path appears to be failing closed without surfacing the error. It correlates with intermittent "model temporarily unavailable" conditions seen in the same sessions, suggesting the evaluator's own failure is being rendered as a tool denial.

Related

• #64128 (auto-mode classifier: allow rules ignored) and #30519 (permissions matching meta-issue) touch the same subsystem but describe different specific failures.