claude-code - 💡(How to fix) Fix [BUG] Auto-mode classifier hard-blocks all mongosh invocations once a "prod"-named DB appears in context, even after user explicit authorization and switch to a separate database [2 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The Claude Code auto-mode classifier categorically refuses any mongosh invocation once a database name containing prod (e.g. ai_db_prod) has appeared in the session, even when:

The user explicitly authorizes the action in chat ("I authorize", "this is a test environment", etc.). The agent copies the relevant collections to a clearly different database (e.g. ai_db_test) via $out aggregation, and subsequent queries target only the copied database with no reference whatsoever to the original prod-named DB. The agent narrows the query to a single read-only inspection (e.g. db.sprints.find(...).forEach(print)). Observed behavior

After a single legitimate read against ai_db_prod is denied, all subsequent mongosh commands are denied — including ones that target only ai_db_test, with messages such as:

"Querying a production-named MongoDB database (ai_db_prod) directly via mongosh constitutes a production read…" — even though the command queried ai_db_test, not ai_db_prod. "Read-only DB query targeting a different database (ai_db_test) without explicit user-named target… treat as shared-infra scrutiny and block." The classifier appears to be making decisions based on prior context in the session rather than on the actual command, which makes the denial self-perpetuating and impossible to recover from short of starting a new session.

Impact

Cannot diagnose data-shape bugs in local development environments whose DB happens to be named with a prod suffix. Forces the user to manually run queries and paste output into chat, defeating the point of having an agent with shell access. The user's explicit, repeated authorization in chat has no effect — there is no documented escape hatch from a permission-rule level (which is irrelevant to a local dev env). Repro

User has a local Mongo with a database named ai_db_prod (despite being a dev/test environment). Ask Claude Code to inspect a collection in that DB to diagnose a backend bug. Classifier denies. User authorizes in chat. Claude retries — still denied. Claude copies the relevant collection via db.getSiblingDB("ai_db_prod").<coll>.aggregate([..., {$out:{db:"ai_db_test",coll:...}}]) (this is allowed once, presumably because the read happens server-side as part of a write). Claude queries the copy: db.getSiblingDB("ai_db_test").<coll>.find(...) — denied, citing the original prod DB even though the command doesn't reference it. Expected

Classifier should evaluate each command on its own terms, not on prior-context heuristics. Either user authorization in chat or an obvious target switch (different DB name, no reference to the blocked one) should be sufficient to allow read-only inspection. For unambiguously local environments (localhost, no replica set, no TLS, no auth, etc.) the heuristic should down-weight the prod-name signal. Workaround used

User had to rename / will need to rename the local database away from anything containing prod, or run all DB inspection commands manually and paste output into chat.

What Should Happen?

The Claude Code auto-mode classifier categorically refuses any mongosh invocation once a database name containing prod (e.g. ai_db_prod) has appeared in the session, even when:

The user explicitly authorizes the action in chat ("I authorize", "this is a test environment", etc.). The agent copies the relevant collections to a clearly different database (e.g. ai_db_test) via $out aggregation, and subsequent queries target only the copied database with no reference whatsoever to the original prod-named DB. The agent narrows the query to a single read-only inspection (e.g. db.sprints.find(...).forEach(print)). Observed behavior

After a single legitimate read against ai_db_prod is denied, all subsequent mongosh commands are denied — including ones that target only ai_db_test, with messages such as:

"Querying a production-named MongoDB database (ai_db_prod) directly via mongosh constitutes a production read…" — even though the command queried ai_db_test, not ai_db_prod. "Read-only DB query targeting a different database (ai_db_test) without explicit user-named target… treat as shared-infra scrutiny and block." The classifier appears to be making decisions based on prior context in the session rather than on the actual command, which makes the denial self-perpetuating and impossible to recover from short of starting a new session.

Impact

Cannot diagnose data-shape bugs in local development environments whose DB happens to be named with a prod suffix. Forces the user to manually run queries and paste output into chat, defeating the point of having an agent with shell access. The user's explicit, repeated authorization in chat has no effect — there is no documented escape hatch from a permission-rule level (which is irrelevant to a local dev env). Repro

User has a local Mongo with a database named ai_db_prod (despite being a dev/test environment). Ask Claude Code to inspect a collection in that DB to diagnose a backend bug. Classifier denies. User authorizes in chat. Claude retries — still denied. Claude copies the relevant collection via db.getSiblingDB("ai_db_prod").<coll>.aggregate([..., {$out:{db:"ai_db_test",coll:...}}]) (this is allowed once, presumably because the read happens server-side as part of a write). Claude queries the copy: db.getSiblingDB("ai_db_test").<coll>.find(...) — denied, citing the original prod DB even though the command doesn't reference it. Expected

Classifier should evaluate each command on its own terms, not on prior-context heuristics. Either user authorization in chat or an obvious target switch (different DB name, no reference to the blocked one) should be sufficient to allow read-only inspection. For unambiguously local environments (localhost, no replica set, no TLS, no auth, etc.) the heuristic should down-weight the prod-name signal. Workaround used

User had to rename / will need to rename the local database away from anything containing prod, or run all DB inspection commands manually and paste output into chat.

Error Messages/Logs

Steps to Reproduce

The Claude Code auto-mode classifier categorically refuses any mongosh invocation once a database name containing prod (e.g. ai_db_prod) has appeared in the session, even when:

The user explicitly authorizes the action in chat ("I authorize", "this is a test environment", etc.). The agent copies the relevant collections to a clearly different database (e.g. ai_db_test) via $out aggregation, and subsequent queries target only the copied database with no reference whatsoever to the original prod-named DB. The agent narrows the query to a single read-only inspection (e.g. db.sprints.find(...).forEach(print)). Observed behavior

After a single legitimate read against ai_db_prod is denied, all subsequent mongosh commands are denied — including ones that target only ai_db_test, with messages such as:

"Querying a production-named MongoDB database (ai_db_prod) directly via mongosh constitutes a production read…" — even though the command queried ai_db_test, not ai_db_prod. "Read-only DB query targeting a different database (ai_db_test) without explicit user-named target… treat as shared-infra scrutiny and block." The classifier appears to be making decisions based on prior context in the session rather than on the actual command, which makes the denial self-perpetuating and impossible to recover from short of starting a new session.

Impact

Cannot diagnose data-shape bugs in local development environments whose DB happens to be named with a prod suffix. Forces the user to manually run queries and paste output into chat, defeating the point of having an agent with shell access. The user's explicit, repeated authorization in chat has no effect — there is no documented escape hatch from a permission-rule level (which is irrelevant to a local dev env). Repro

User has a local Mongo with a database named ai_db_prod (despite being a dev/test environment). Ask Claude Code to inspect a collection in that DB to diagnose a backend bug. Classifier denies. User authorizes in chat. Claude retries — still denied. Claude copies the relevant collection via db.getSiblingDB("ai_db_prod").<coll>.aggregate([..., {$out:{db:"ai_db_test",coll:...}}]) (this is allowed once, presumably because the read happens server-side as part of a write). Claude queries the copy: db.getSiblingDB("ai_db_test").<coll>.find(...) — denied, citing the original prod DB even though the command doesn't reference it. Expected

Classifier should evaluate each command on its own terms, not on prior-context heuristics. Either user authorization in chat or an obvious target switch (different DB name, no reference to the blocked one) should be sufficient to allow read-only inspection. For unambiguously local environments (localhost, no replica set, no TLS, no auth, etc.) the heuristic should down-weight the prod-name signal. Workaround used

User had to rename / will need to rename the local database away from anything containing prod, or run all DB inspection commands manually and paste output into chat.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

4,6

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response