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

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) 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

```shell

```

### 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

```markdown
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_

Start by reproducing the denial in an Auto Mode session using the documented SSH, docker, sqlcmd/pyodbc command variants, then inspect ~/.claude/settings.json and the reported classifier messages. Done means determining why the allow-list is overridden and providing consistent authorization or an inspectable explanation for the credential-related block.

Written by the indexing model from the issue text.