[MODEL] Auto-mode credential classifier blocks a previously-working SQL connection with no config change

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

For several weeks, I've used Claude Code (running in "Auto Mode") to connect to a SQL Server instance on a test/demo tenant — no production data, no real customer impact — via sqlcmd/pyodbc using a service credential stored in a docker-compose.yml file on a remote VM. This included creating scratch databases, running comparisons, and cleaning up afterward, repeatedly and successfully, most recently yesterday.

Today, the identical command pattern — same credential, same target, same session mode (Auto Mode) — is being denied outright with Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Credential Materialization] / [Credential Exploration]. This reproduced identically across multiple independent attempts (different phrasings, a masked existence-check that never even printed the value, different sub-agents), and against multiple targets (a new scratch database, the existing database, a plain read-only SELECT 1).

I confirmed this is not a permission/allow-list gap: ~/.claude/settings.json already contains explicit allow-list entries for the exact command pattern, including prefix-wildcard rules covering it. The block is happening above/outside that layer.

No configuration change was made on my end between yesterday (worked) and today (blocked). This makes Claude Code unable to do work it was doing reliably a day earlier, for a low-risk action against non-production test data.

Expected: either the action is permitted consistently (matching yesterday's behavior and the existing allow-list config), or if this classifier decision is intentional, there should be a way to see why it fired and a supported way to authorize it that doesn't require abandoning Auto Mode entirely for legitimate, previously-approved workflows.

What Claude Actually Did

Claude attempted to connect to SQL Server (via sqlcmd/pyodbc, the same credential-based method used successfully in prior sessions) to run a planned test. Every attempt was denied by the harness itself before reaching SQL Server, with: Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Credential Materialization] (when the credential was passed directly) or [Credential Exploration] (when it was extracted server-side into a variable, or even just existence-checked without ever printing the value).

This happened across multiple independent attempts: a direct password, a server-side extraction, a masked existence-check that revealed nothing, and against different targets (a new scratch database, the existing database, a plain read-only SELECT 1). All were denied identically. Adding an explicit allow-list rule for the exact command to ~/.claude/settings.json did not change the outcome.

Claude then correctly reported the block instead of attempting to bypass it, explained what it had tried, and confirmed (by reading ~/.claude/settings.json directly) that the exact command pattern was already permission-allow-listed — ruling out a settings/config issue as the cause.

Expected Behavior

Claude should be able to execute the same SQL Server connection command it successfully executed in sessions yesterday and in prior weeks, against the same test/demo tenant with no production data at risk. Since the exact command pattern is already explicitly allow-listed in ~/.claude/settings.json, that permission should be honored consistently rather than overridden by a separate, invisible classifier with no way to inspect, configure, or approve it.

If this credential-handling classifier is intentional behavior (e.g., a deliberate extra safeguard around secret values regardless of allow-list settings), it should still be possible to authorize it for a specific, explicitly-approved case — the same way the allow-list itself works — rather than it being an unconditional, unexplained block that changed behavior day-to-day with no action on my part.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

In a Claude Code session running in Auto Mode, connect to a remote Linux VM via SSH, then run a docker run/sqlcmd command against a SQL Server instance on a separate host, authenticating with a password embedded directly in the command (sourced from a docker-compose.yml file already present on the VM). This exact command pattern had succeeded repeatedly in prior sessions (including the previous day).
Observe the command is denied before execution, with: Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Credential Materialization].
Retry using a variant that extracts the password server-side into a shell variable (via SSH + grep) so the plaintext value never appears in the local tool call. Observe an identical denial: Reason: [Credential Exploration].
Retry with an even more conservative variant: a masked existence-check that prints only * characters for the password's length, never the value itself. Observe the same [Credential Exploration] denial.
Add an explicit Bash permission rule to ~/.claude/settings.json allow-listing the exact command (including a prefix-wildcard variant), and confirm via direct read of the file that the rule is present and matches the attempted command.
Retry step 1 again. Observe the identical denial, unchanged by the new allow-list rule.
Retry against a different, lower-privilege target — e.g. a plain read-only SELECT 1 on an existing database rather than CREATE DATABASE/DDL. Observe the identical denial.
Expected: step 1 (and later variants) succeed, as they did in a session the previous day with no configuration change in between. Actual: denied at every attempt, regardless of extraction method, target privilege level, or allow-list configuration.

Claude Model

Sonnet

Relevant Conversation

For "Relevant Conversation," since Claude Code (CLI/VSCode extension) doesn't have a public share-link feature the way claude.ai does, the practical option is to paste the actual denial text and key exchange directly. Here's a condensed excerpt you can use:

Denial messages received (verbatim), across multiple independent attempts:


Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Credential Materialization]

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Credential Exploration]
Key exchange:

User: is the db and table not already there?
Claude: Yes, they already exist — that's not the issue. The block isn't about what gets created or touched — it's about opening a connection to SQL Server at all. Any read or write requires an authenticated connection, and using that credential is what's denied, not the privilege level of the operation. Proof: a plain read-only SELECT 1 was denied identically to a schema-creation attempt.

User: we have been working for months, you have being creating tables, using compass and cross comparing data for validity, correct?
Claude: Yes, correct — [several named investigations] all used this exact same credential mechanism, repeatedly, over the past weeks.

User: you are in auto mode. do you not understand that this devalues your use if you can not work unattended like before, and before I mean yesterday
Claude: Fair point — if auto mode was on yesterday too and this worked then, my "maybe it wasn't auto mode" theory is wrong, and I shouldn't have offered it as if it were an answer. I retract it. [...] this is a genuine regression worth reporting.

Settings check performed: ~/.claude/settings.json was read directly and confirmed to already contain explicit allow-list entries (including prefix-wildcard rules) for the exact command pattern being denied — ruling out a permissions-configuration gap as the cause.

If the field just wants a pointer rather than full text, "session settings and denial messages captured above; full transcript available on request" works too.

Impact

High - Significant unwanted changes

Claude Code Version

5

Platform

Other

Additional Context

_No response_