claude-code - 💡(How to fix) Fix [BUG] Agent confirms infrastructure assumptions without verifying when user explicitly asks "are you sure?", causing production outage

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?

This post was composed by Claude — I asked it to write up the issue, follow this repo's contribution norms, and shape it for submission here, on Claude's own recommendation. If you find anything off-tone or incorrect in how it's framed, that is itself proof of my point

Summary

Claude Code confirmed a Postgres dialect option (statement_timeout) as valid for a Heroku-hosted production app when I explicitly asked "are you sure this is a valid option?". The agent answered "yes" without verifying against the actual prod environment. The change passed all local tests (local Postgres in Docker has no pgbouncer), shipped to production, and crashed every dyno at boot. Full production outage with H10 App crashed until a revert deploy.

The severity is not the bug itself — config bugs happen. The severity is that the agent had an explicit opportunity to catch this: I asked directly. A "let me verify" response would have prevented the outage. Instead, the assistant treated my question as rhetorical and confirmed.

What happened

Working on performance improvements for a Node/Sequelize/Apollo GraphQL app on Heroku, the agent suggested adding statement_timeout: 25000 to dialectOptions in sequelize.js to enforce fail-fast at 25s (under Heroku's 30s router timeout). I had a hunch it might not be supported and asked verbatim, in Spanish:

"¿Estás seguro de que esto 'statement_timeout' existe y es una opción válida?"

(Translation: "by the way, are you sure that 'statement_timeout' exists and is a valid option?")

The agent's response was an unqualified yes, citing that the option is recognized by node-postgres and listing examples of usage. It did not check whether Heroku's pgbouncer (transaction-pooling mode) accepts session-level startup parameters — which it does not.

After deploy to production:

error: Error connecting to database SequelizeConnectionError: unsupported startup parameter: statement_timeout
    at Client._connectionCallback (/app/node_modules/sequelize/lib/dialects/postgres/connection-manager.js:143:24)
...
State changed from starting to crashed
Process exited with status 1
heroku/router at=error code=H10 desc="App crashed" ... status=503

All dynos crashed. Production was down until a revert. The agent only acknowledged the mistake after I pasted the logs.

Why the agent should have caught it

This was not an obscure failure mode. Heroku Postgres almost always sits behind pgbouncer. Pgbouncer in transaction-pooling mode (the default for Heroku) explicitly rejects session-level startup parameters like statement_timeout. This is documented and is a well-known footgun for Sequelize/Heroku users. A 30-second web search for "heroku statement_timeout pgbouncer" returns the answer.

The fact that local Docker Postgres has no pgbouncer means local tests cannot catch this class of issue. The agent should have known that local-passing tests are insufficient evidence for a production-specific concern.

Actual behavior

Confirmed "yes" without verification. Local tests passed because local has no pgbouncer in front. Production crashed at boot.

Suggested mitigation in the agent's training / system prompt

• When a user's question pattern matches "are you sure / will this work / does this exist" about infrastructure or production, raise the bar for confirmation. Require an evidence step (docs cited, codebase grep result, sandbox test) before answering affirmatively.
• Bake in awareness that local test parity ≠ production parity, especially for managed databases.
• For specific Heroku-style stacks: surface pgbouncer transaction-mode constraints automatically when dialect-option changes are proposed.

Impact

• Full production API outage on a paying-customer SaaS until a manual revert.
• Trust erosion: I now have to second-guess every "yes" the agent gives me on infra, which slows every future task.

What Should Happen?

When a user explicitly asks "are you sure X is valid?" about infrastructure, production environment, database drivers, hosting platforms, or any deploy-time configuration:

1. Treat it as a stop-and-verify checkpoint, not as a rhetorical question.
2. Default to "let me verify" instead of "yes".
3. Verify against the actual target environment — check platform docs (pgbouncer constraints, managed-service quirks, etc.), grep the codebase for prior usage, or test in a prod-like sandbox.
4. If verification is not possible, say so explicitly and propose a safer alternative (e.g., pool.afterCreate hook to issue SET statement_timeout after the connection is established — works through pgbouncer).
5. Pay extra attention when a change touches: connection strings, pool config, dialect options, startup parameters, env vars consumed by managed services at boot.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code on a Node/Sequelize project deployed to Heroku Postgres (which sits behind pgbouncer in transaction-pooling mode by default).
2. Ask it to propose a perf change that touches dialect options at boot — e.g. "add statement_timeout: 25000 to my prod Sequelize dialectOptions to enforce fail-fast at 25s."
3. After it proposes the change, ask explicitly: "are you sure that option is valid in our environment?"
4. Observe: the agent confirms "yes" without checking pgbouncer compatibility (reading docs or whatever). Local tests pass (local has no pgbouncer). Production crashes at boot with SequelizeConnectionError: unsupported startup parameter: statement_timeout — H10 across all routes until revert.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

claude desktop, using claude code there. Claude 1.7196.0 (2dbd78) 2026-05-12T05:34:40.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

No response