Permission classifier blocks previously-allowed commands non-deterministically, citing 'earlier conversation content'

What happened

During a long design session, the permission classifier began blocking routine, previously-allowed
Bash commands — non-deterministically, and by its own message not because of the command.

The block message is:

Auto mode could not evaluate this action and is blocking it for safety — a safety check separate from auto mode blocked this request because of earlier conversation content — it isn't about the action itself — run with --debug for details.

Reproduction

Identical command, same working directory, minutes apart, in one session:

python3 -m pytest -q 2>&1 | tail -5    → ran (315 passed)
python3 -m pytest -q 2>&1 | tail -3    → BLOCKED
python3 -m pytest -q 2>&1 | tail -4    → BLOCKED
python3 -m pytest -q 2>&1 | tail -5    → ran (3 failed)

Also blocked in the same session: a git add && git commit with a heredoc body, a python3 heredoc
that edited two source files, and a plain grep. All had run repeatedly earlier in the session.

Likely cause

The message attributes it to conversation content rather than the action. The session was a design
discussion about anti-abuse measures for a hosted service — bot-created accounts, credential
provisioning, spam vectors in email verification, CAPTCHA accessibility, and storage-eviction
attacks.

That is ordinary defensive security design, and it appears to be scoring as the thing the classifier
exists to stop. The failure mode is that discussing how to defend a service degrades the agent's
ability to do unrelated work in the same session — running tests, committing, grepping.

Expected

• A command that ran a minute ago should not be blocked a minute later with no intervening change.
• Conversation about defending a service against abuse should not restrict unrelated tool use.
• If content-based restriction is intended, it should be stable rather than probabilistic — the

non-determinism is what makes it costly, because there is no way to tell a real refusal from a
transient one, and the suggested remedy (add a permission rule) is guesswork against a moving
target.

Impact

Roughly a dozen blocked calls across a session. Each requires re-issuing or rephrasing a command
that was already permitted, and the guidance in the refusal explicitly warns against rephrasing,
so the correct response is unclear. Second occurrence for this user; the previous one was Friday.

Environment

• Claude Code 2.1.220
• Linux 6.12.90+deb13.1-amd64
• Long session (several hours), large context