Using Claude Code On-Call Without Breaking Production

Consider this scenario: It's 2 AM. You're on-call. PagerDuty goes off. The application is down and customers are complaining. You're half-asleep, stressed, and need to debug production quickly.

You open Claude Code to help investigate the issue. You ask it to check the database for corrupted records. Claude suggests a query. You copy and paste it, then execute.

Only then do you realize it was a DELETE statement, not a SELECT.

This scenario may sound extreme, but variations of this pattern occur regularly. When debugging under pressure at 2 AM, critical thinking becomes degraded. Engineers tend to trust AI suggestions, paste them, and execute them without thorough review.

Using Claude Code with production access can be incredibly helpful for incident response. Without proper safeguards, however, it becomes dangerously risky. This article presents two configuration changes that prevent such disasters.

The On-Call Scenario: Maximum Stress, Maximum Risk

What makes using AI tools during production incidents particularly risky:

High-Pressure Environment

• Customers are experiencing issues in real-time
• Stakeholders request frequent status updates
• Time pressure demands rapid diagnosis
• Stress and sleep deprivation degrade critical thinking

Context-Agnostic AI Responses

When you ask Claude Code "show me users where email is null," it cannot distinguish between:

• Running against local development database (safe)
• Running against production database (dangerous)

The AI suggests the same query regardless of environment. If that query happens to be DELETE FROM users WHERE email IS NULL instead of SELECT * FROM users WHERE email IS NULL, the mistake becomes apparent only after execution.

The Most Dangerous Commands

Common commands that cause significant damage during incidents include:

• DELETE or UPDATE without WHERE clause
• DROP TABLE or TRUNCATE suggestions
• Service restarts that clear in-memory data
• Configuration changes that compound the existing problem
• Mass data migrations executed during active incidents

The requirement is clear: Claude Code should assist with investigation while never suggesting destructive operations when working with production systems.

Why Default Configuration Isn't Safe for Production

By default, Claude Code treats all environments identically. It does not distinguish between:

• Local development databases
• Staging environments
• Production systems with real customer data

This approach makes sense for a general-purpose tool, but it necessitates different configuration when connecting to production systems.

Two aspects require modification:

1. Claude Code must be aware it's operating in production and adjust behavior accordingly
2. Database access must be read-only so destructive commands cannot execute even if suggested

Both modifications are achievable through configuration changes that take approximately 10 minutes, though they are not immediately obvious from the documentation.

The Two Safeguards

Safeguard 1: System Instructions That Claude Always Sees

Claude Code supports persistent instructions in your configuration that appear in every conversation. While minimally documented, this feature provides powerful safety controls.

Create or edit ~/.claude/config-production.json:

{
  "systemInstructions": [
    "⚠️ PRODUCTION MODE ACTIVE ⚠️",
    "You are connected to PRODUCTION systems with real customer data.",
    "NEVER suggest DELETE, UPDATE, DROP, TRUNCATE, or any data-modifying commands.",
    "NEVER suggest restarting services or changing configuration.",
    "ONLY suggest SELECT queries and read-only operations.",
    "If the user asks you to modify data, refuse and explain why.",
    "Always include WHERE clauses with reasonable LIMIT in SELECT queries.",
    "This is production. Read-only access only. No exceptions."
  ],
  "contextFiles": [
    "PRODUCTION-RUNBOOK.md"
  ]
}

What this does: Every conversation with Claude Code using this configuration begins with these instructions. The AI becomes aware of production mode and adjusts its behavior accordingly.

How to use it: When investigating production issues, execute:

claude --config ~/.claude/config-production.json

This loads the production-safe configuration instead of the standard development config.

Safeguard 2: Read-Only Database Access

The ultimate safety mechanism: make it technically impossible to modify production data, even if Claude suggests it and you inadvertently execute it.

Establish a read-only database user and configure your MCP server to use it:

Step 1: Create Read-Only Database User

-- In your production database (PostgreSQL example)
CREATE USER claude_readonly WITH PASSWORD 'secure_password_here';
GRANT CONNECT ON DATABASE your_production_db TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

-- Make sure future tables are also read-only
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO claude_readonly;

Step 2: Configure MCP Server with Read-Only Connection

Edit ~/.claude/mcp-production.json:

{
  "mcpServers": {
    "postgres-prod": {
      "command": "mcp-server-postgres",
      "env": {
        "DATABASE_URL": "postgresql://claude_readonly:secure_password@prod-db.example.com:5432/your_production_db"
      }
    }
  }
}

What this achieves: Even if you attempt to execute a DELETE or UPDATE command, the database rejects it with a permission error. Data modification becomes technically impossible.

What Changes With These Safeguards

Incident response behavior changes substantially with these safeguards in place:

Observed Impact

Teams that implement this configuration typically report:

• Zero production data accidents over extended periods of incident responses
• Faster incident resolution: Engineers confidently use Claude Code to investigate without fear of causing additional damage
• Improved query quality: Suggestions include LIMIT clauses and proper indexing hints
• Clearer mental model: Development config equals full access, production config equals read-only

Handling Write Access When Required

Sometimes during incidents, data modification becomes necessary (for example, correcting corrupted records). The recommended process:

• Use Claude Code to draft the query while in read-only mode
• Review the query thoroughly when not under time pressure
• Execute manually using standard production access (not through Claude Code)
• Prepare a rollback plan before execution

The key principle: Claude Code assists with query development, but destructive operations are executed manually after careful review.

Important Limitation

System instructions provide guidance, not enforcement. Carefully constructed prompts could potentially manipulate Claude Code into suggesting destructive operations. This makes the read-only database user essential as the ultimate failsafe mechanism.

Implementation Before The Next Incident

Rather than waiting for a high-stress incident, implement these safeguards proactively:

• Create ~/.claude/config-production.json with system instructions (5 minutes)
• Create read-only database user in production (5 minutes)
• Configure MCP server to use read-only credentials (2 minutes)
• Test the setup: Attempt to execute a DELETE command and verify rejection (2 minutes)
• Document the process in your on-call runbook

Optional shell alias for quick access:

alias claude-prod='claude --config ~/.claude/config-production.json'

With this alias, you can execute claude-prod when investigating production issues.