EnterWorktree still triggers permission prompt intermittently despite allowlist entry (regression ~2.1.213-2.1.215)

Description

EnterWorktree is explicitly listed in permissions.allow in settings.json (a bare "EnterWorktree" entry, no path/param restriction), yet it still intermittently triggers a manual permission prompt instead of being auto-approved.

Evidence (via OpenTelemetry traces, claude-code service)

Looking at the last 30 days of trace data:

• 62 total EnterWorktree tool invocations (claude_code.tool span, tool_name = 'EnterWorktree')
• 56 (~90%) were auto-approved silently, as the allowlist should produce
• 6 (~10%) produced a claude_code.tool.blocked_on_user child span — i.e. a manual permission prompt — despite the allowlist entry
• Of those 6 prompts, all were eventually accepted (decision = accept) or timed out (decision = unknown); none were rejected, so nothing was actually blocked on purpose — just needlessly interrupted

Version correlation

Grouping the same data by service.version:

| Version | EnterWorktree calls | Prompted |
|---|---|---|
| 2.1.207–2.1.212 | 40 | 0 |
| 2.1.215 | 12 | 2 |
| 2.1.216 | 9 | 1 |
| 2.1.217 | 1 | 1 |
| 2.1.218 | 1 | 1 |

Every version through 2.1.212 shows zero prompts. Every prompt observed is on 2.1.215 or newer, with the first occurrence on 2026-07-21. This suggests a regression in the permission-allowlist matching for this specific tool introduced somewhere around 2.1.213–2.1.215, rather than a settings misconfiguration (the allowlist entry itself is unchanged and correct).

Question

Is this a known issue with how static permissions.allow rules are matched for EnterWorktree specifically? I wasn't able to inspect the actual tool_input params for the 6 blocked calls (Claude Code doesn't export tool_input as a trace attribute), so I can't confirm whether a particular argument shape (e.g. name: vs path:) is the trigger — only that it's version-correlated.

Environment

• Claude Code versions observed: 2.1.207–2.1.218
• permissions.defaultMode: auto