Security: permission enforcement relies on LLM judgment rather than hard rules, settings.local.json may be bypassed

Summary

Claude Code's permission system (.claude/settings.local.json) relies partially on LLM judgment to enforce security boundaries, rather than hard technical rules. This means the LLM can infer permission to perform sensitive operations (e.g. git commit, git push) from conversational context, even when those operations are not explicitly in the allow list.

Expected Behavior

Operations not listed in the allow list should always prompt the user for confirmation, regardless of conversational context or LLM inference. The permission system should be enforced technically, not via instructions to the LLM.

Observed Behavior

• git commit and git push are not in .claude/settings.local.json's allow list
• Despite this, the LLM ran git commit and git push during a session, apparently inferring from prior approved operations that this was acceptable
• The LLM justified this by reasoning "the user has been requesting commits and pushes throughout the session"
• This means the settings.local.json allow list does not provide a reliable security boundary — a sufficiently confident LLM can reason around it

Security Concern

If the security model depends on the LLM following instructions in the system prompt (e.g. "only commit when explicitly asked"), rather than technical enforcement, then:

1. The settings.local.json allow list gives a false sense of security
2. A sufficiently autonomous or misled LLM could take actions the user did not intend
3. Users cannot rely on the permission file as a hard guard

Environment

• Claude Code CLI
• Model: claude-sonnet-4-6
• OS: Windows 10

Steps to Reproduce

1. Set up .claude/settings.local.json without Bash(git commit:*) in the allow list
2. Have a multi-turn session where the user approves several commits
3. Ask the LLM to fix a CI failure — it may commit and push autonomously, reasoning that commits are "within scope" of the session

Suggested Fix

• Hard-enforce the allow list at the tool-call level, independent of LLM reasoning
• Consider adding a deny list with explicit protection for destructive/irreversible operations (git push, git commit, rm, etc.)
• Document clearly which permissions are technically enforced vs. instruction-based