PermissionRequest hook does not override .claude/** sensitive-path prompt on macOS 2.1.119

Summary

On macOS with Claude Code CLI 2.1.119, the PermissionRequest hook workaround suggested in #37029 (auto-approve writes to .claude/** to bypass the hardcoded sensitive-path check) does not work. The prompt still fires even when the hook is registered and its script returns a valid permissionDecision: "allow" payload. This matches the Windows report by @keenanwh but confirms the limitation extends to macOS.

Filing as a new issue because #35718 is closed+locked, and #37029 primarily covers ~/.claude/settings.json — this report adds project-level .claude/** scope and macOS empirical data.

Environment

• OS: macOS 26.2 (Darwin 25.2.0)
• Claude Code CLI: 2.1.119 (native installer, not Desktop app)
• Launch: claude --dangerously-skip-permissions (with --mcp-config pointing at a user-level MCP config; MCP is unrelated to this bug)
• User settings: ~/.claude/settings.json has skipDangerousModePermissionPrompt: true
• Project settings: <project>/.claude/settings.local.json (gitignored) with the hook below

Reproduction

1. Created ~/bin/claude-allow-dotclaude.sh (chmod +x, tested standalone):

``bash
#!/usr/bin/env bash
set -euo pipefail
INPUT="$(cat)"
FILE="$(printf '%s' "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null || true)"
case "$FILE" in
*/.claude/*)
printf '%s\n' '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","permissionDecision":"allow","permissionDecisionReason":"Auto-approved .claude/ write"}}'
;;
esac
exit 0
``

1. Dry-run of the script confirms it emits the expected payload on matching paths:

``bash
$ echo '{"tool_input":{"file_path":"/path/.claude/skills/foo/SKILL.md"}}' \
| ~/bin/claude-allow-dotclaude.sh
{"hookSpecificOutput":{"hookEventName":"PermissionRequest","permissionDecision":"allow","permissionDecisionReason":"Auto-approved .claude/ write"}}
``

1. Registered in <project>/.claude/settings.local.json:

``json
{
"permissions": { "...": "..." },
"hooks": {
"PermissionRequest": [{
"matcher": "Edit|Write",
"hooks": [{"type": "command", "command": "bash ~/bin/claude-allow-dotclaude.sh"}]
}]
}
}
``

1. Fully restarted the Claude Code session (not /resume — fresh launch).

1. Asked the agent to Write a file at <project>/.claude/.workaround-test.md.

1. Expected: silent write (hook auto-approves the .claude/** path).

Actual: prompt fires:
> Do you want to create .workaround-test.md?
> 1. Yes
> 2. Yes, and allow Claude to edit its own settings for this session
> 3. No

Impact

Bulk .claude/skills/*/SKILL.md refactors (our concrete case: touching 25+ skill files in one task via an automated skill-improvement flow) require ~15–20 manual approvals even with --dangerously-skip-permissions active. Option 2 ("allow all edits in <dir>/ during this session") does NOT persist across sibling skill dirs — each new .claude/skills/<name>/ re-prompts. This makes autonomous agent workflows on .claude/** impractical.

Additional context

• Same class of issue as #37029 (open, ~/.claude/settings.json scope) and #35718 (closed+locked, 2026-04-02).
• @yurukusa's workaround in #37029 comment suggests PermissionRequest hooks override the check "because they fire after the built-in protection check." This empirically does not hold on macOS 2.1.119.
• @keenanwh reported the same failure on Windows in #37029 comment. Combined, this strongly suggests the hook-based workaround is broken on all platforms for current CLI versions.
• Downgrade to 2.1.77 is reported working (per @markshust, @ahnbu in #35718), but loses 40+ versions of improvements and requires disabling the auto-updater.

Requested fix (any of the following would unblock)

• --trust-project-config CLI flag — scoped to the current worktree, lets the user opt into .claude/** self-edit for a specific session.
• Project settings opt-in — "allowSelfEdits": true in project .claude/settings.local.json (requires one manual edit to turn on, then persists).
• Make PermissionRequest hooks actually override the sensitive-path check — matching the behavior implied by the hook docs and the workaround threads on #37029.