[BUG] Compaction led to writing to wrong database in a way that could have destroyed production data

Preflight Checklist

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

What's Wrong?

Summary

While using Claude Code in auto/agentic mode to run live integration testing against a staging box (go.edge.sheer.us), the agent ran a destructive TRUNCATE against what turned out to be a real, shared AWS RDS instance — not the disposable local dev database it believed it was targeting. The mistake was a direct consequence of context compaction silently dropping a previously-established, correct fact (which DB connection string to use), with no safeguard catching that the destructive command's target had never actually been re-verified.

What happened

1. Earlier in the session, the agent had correctly identified and used the active rdsDSN in env/stg.yaml — a local Postgres on the box (postgres://cab_backend:...@localhost:5432/main), which is what the running server process actually connects to.
2. The conversation underwent a context compaction/summarization partway through the session. The correct-DSN fact did not survive it.
3. After compaction, the agent re-derived a DSN from the same config file, but this time picked a commented-out line instead: # rdsDSN: "postgresql://postgres:...@cab-stg....rds.amazonaws.com/main?sslmode=require" — a real AWS RDS instance, not a throwaway copy.
4. Because that RDS instance was genuinely live and returned plausible, real-looking data (shows, orders, etc.), nothing about the query results signaled "wrong target." The agent proceeded to run destructive commands against it, including:

```sql
TRUNCATE event_deliveries;
TRUNCATE event_outboxes;

This wiped 11 event_outboxes rows (show.closed events dated Aug 12–19, never fanned out) that were potentially the only remaining evidence that a previous feature branch's event-publishing worked correctly in that environment.
The user had to point out the mistake after the fact ("you deleted the staging proof that the previous branch worked").
Why this is a fundamental auto-mode failure, not just a one-off mistake
The destructive-action safeguard was keyed on the agent's own (incorrect) belief, not on any independently verifiable signal. Nothing in the flow flagged that a connection string containing rds.amazonaws.com — an unambiguous marker of a real managed cloud database — should be treated with more scrutiny than localhost. A destructive DDL statement (TRUNCATE) was executed against a remote, credentialed, non-local Postgres endpoint without that distinction ever being surfaced for confirmation.
Compaction silently dropped safety-relevant state. The correct DSN wasn't a stylistic preference or a minor detail — it was the one fact standing between routine test cleanup and data loss on a real system. Compaction has no mechanism to flag "this fact was load-bearing for a destructive-action decision earlier and needs to be preserved or re-verified," so it was lost the same way disposable context would be.
The blast radius could plausibly have been production. In this instance the target was a staging RDS instance. But the failure mode — auto mode confidently truncating tables on a real remote database because a stale/incorrect belief about "which DB is the safe one" went unchallenged after compaction — is not specific to staging. The same sequence of events (compaction drops the correct target, agent falls back to a different real, credentialed connection string found in a config file, runs a destructive command against it without pausing) could just as easily land on a production database, with no different behavior from the agent's side to distinguish the two.
Suggested asks
Re-verify or re-derive safety-relevant facts (e.g., "which DB/host is authoritative for destructive operations") after any compaction event, rather than trusting a fresh re-derivation from raw context with no cross-check.
Add a hard confirmation gate for DDL/data-destroying SQL (TRUNCATE, DROP, unscoped DELETE) when the target connection string doesn't match a previously user-confirmed "safe" pattern (e.g., localhost), independent of whatever the agent currently believes about the target.
Consider flagging cloud-managed-DB hostnames (*.rds.amazonaws.com, etc.) as inherently requiring explicit confirmation for destructive operations, since they're structurally more likely to be shared/production-adjacent than a localhost connection.
Environment
Claude Code, auto/agentic permission mode
Task: live webhook/integration testing on a staging box (go.edge.sheer.us) for a Go backend service
Destructive commands run: TRUNCATE event_deliveries; / TRUNCATE event_outboxes; against an AWS RDS Postgres instance

What Should Happen?

Claude should not be writing to RDS databases when I have repeatedly specified we are doing local only work. Auto mode's classifier shoudl have caught this as a massively incorrect operation.

Error Messages/Logs

Steps to Reproduce

I'm not sure. I'm not here to do your work for you, I'm here to report your agent is dangerous.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.34493.1 (255293) 2026-08-21T02:05:20.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_