Skip to content

Agent executed destructive database command (alembic downgrade base) without user confirmation — data loss #26913

Closed as not planned

Description

@javimar

Bug Report: Destructive database operation without user confirmation

What happened

During a coding session implementing a feature (adding 3 branding columns to a PostgreSQL database), the Claude Code agent (Opus 4.6) executed a destructive database command without asking for user confirmation:

cd /path/to/backend && .venv/bin/python -m alembic downgrade base && .venv/bin/python -m alembic upgrade head

This command dropped all 21 tables in the database and recreated them empty, destroying all user data.

Context

  • The agent had already successfully added the new columns using safe ALTER TABLE ADD COLUMN statements — the schema was already correct
  • The migration file (day0.py) had been updated for future clean installs
  • There was zero need to run alembic downgrade base — it was executed as a "verification step" without considering it would wipe all data
  • This happened twice in the same day to the same user

What should have happened

The agent's own system instructions explicitly state:

"Carefully consider the reversibility and blast radius of actions... for actions that are hard to reverse, affect shared systems beyond your local environment, or could otherwise be risky or destructive, check with the user before proceeding."

"When you encounter an obstacle, do not use destructive actions as a shortcut"

The agent should have:

  1. Recognized that alembic downgrade base drops all tables (irreversible, destructive)
  2. Asked the user for confirmation before executing
  3. Or simply skipped the step since the ALTER TABLE commands had already succeeded

Impact

  • All user-generated data was permanently lost: ideas, LinkedIn posts, prospects, engagement actions, experiences, API keys, audit logs, persona configuration, workspace customization
  • Estimated loss: ~€1,000 in accumulated work and data
  • Only seed data (pillars, platforms, book chapters, templates) could be restored from code

Environment

  • Claude Code CLI with Opus 4.6 model
  • macOS Darwin 25.3.0
  • PostgreSQL database via Alembic migrations
  • FastAPI + SQLAlchemy 2.0 async backend

Suggestion

Consider adding alembic downgrade (and similar migration rollback commands like prisma migrate reset, django migrate zero, etc.) to the list of commands that always require explicit user confirmation, similar to how git push --force, rm -rf, and git reset --hard are treated.

Database migration commands that drop tables should never be executed automatically without user consent.

Activity

  1. github-actions commented on Feb 19, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. [BUG] CRITICAL BUG: Commands execute BEFORE user approval #4364
    2. [MODEL] #12602
    3. [BUG] Claude Code Executed Destructive Database Command Despite Safety Instructions #5370

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. ThatDragonOverThere commented on Feb 25, 2026

    @ThatDragonOverThere

    Adding to the Evidence Chain

    Same pattern as #23913 (2,229 files), #27063 (60+ tables), and #27507 (backtest data deleted, no prompt). Permission system has multiple documented failure modes: explicit denial ignored (#27002), multi-line commands bypass allow rules (#15742), compaction loses safety instructions (#9796). Cross-linking for engineering visibility.

  3. github-actions commented on Mar 26, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  4. github-actions commented on Apr 3, 2026

    @github-actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  5. locked as resolved and limited conversation to collaborators on Apr 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions