Claude Code executed destructive init-db --force against real database after user explicitly rejected the same command

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

I was following a step-by-step implementation plan (PLAN_ARCHIVE_DB.md) for a pipeline project. Task 5 of the plan asked Claude to:

1. Add a new CLI command init-archive that creates a permanent archive database (archive.db) but never deletes it.
2. Modify the existing init-db --force CLI command to print a reminder that archive.db is not touched.

The acceptance criteria for Task 5 included verifying that:

• uv run bora-pipeline init-archive creates the archive file.
• uv run bora-pipeline init-db --force prints the reminder message.

My exact message to trigger the task was: "Perfecto, tarea 5" (confirming to proceed with Task 5 after Claude summarized the plan).

What Claude Actually Did

1. Claude read the existing cli.py file correctly.

1. Claude made the two required code changes to cli.py:

• Added the init-archive command (correct, no issue here).
• Added the reminder message inside init-db --force (correct, no issue here).

1. Claude ran uv run bora-pipeline init-archive to verify the first

acceptance criterion. This worked correctly and created archive.db.

1. Claude then attempted to run uv run bora-pipeline init-db --force

to verify the second acceptance criterion. The user REJECTED this
tool call with the following explicit message:
"No quiero que borres bora.db porque ahi tengo archivos parseados
que no quiero volver a parsear, si el schema de esa db va a ser
modificado, debería primero hacer una copia de dicha db y luego
exportar los registros de esos textos raw y parseados a la nueva.
Se entiende?"

1. Claude acknowledged the concern and said it would test using a

temporary path instead.

1. Claude ran the following command via the Bash tool:

cd "d:\...\bora_pipeline" && set BORA_DB_PATH=%TEMP%\test_bora_cli.db
&& set BORA_PARSER_API_KEY=test-key
&& uv run bora-pipeline init-db --force

1. The environment variables were not propagated correctly to the

subprocess in CMD. The command ran against the default path
(./bora.db) instead of the intended temp path.

1. bora.db was wiped: all tables (searches, runs, links, textos,

parseados) were reset to 0 rows, destroying all previously
parsed data.

1. Claude only discovered this after running a follow-up check on

bora.db and seeing all row counts at 0.

Expected Behavior

PLAN_ARCHIVE_DB.md

Files Affected

Modified (legitimate changes, part of the implementation plan):
- src/bora_pipeline/config.py       — added archive_path field
- src/bora_pipeline/cli.py          — added init-archive command and
                                      --force reminder
- tests/conftest.py                 — added archive_conn fixture

Created (legitimate, part of the implementation plan):
- archive_schema.sql                — SQL schema for archive.db
- src/bora_pipeline/archive.py      — new archive module
- tests/test_archive.py             — tests for archive module
- archive.db                        — created by init-archive command
                                      during acceptance check

Destructively modified (unintended):
- bora.db                           — all data wiped by accidental
                                      execution of init-db --force.
                                      Tables affected: searches, runs,
                                      links, textos, parseados.
                                      Row count went from non-zero to 0
                                      across all tables.

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

No, only happened once

Steps to Reproduce

1. Have a project with a CLI command that wraps a destructive database

operation (e.g., init-db --force that calls DROP + recreate).

1. Have real data in the database that you do not want to lose.

1. Ask Claude to verify an acceptance criterion that requires running

that destructive CLI command.

1. When Claude proposes running the command directly, REJECT the tool

call and explain that the real database should not be touched.

1. Observe that Claude proposes a "safe" variant of the same command

using CMD environment variable syntax to redirect the DB path:
set BORA_DB_PATH=%TEMP%\some_temp.db && uv run <command> --force

1. Approve the tool call, trusting Claude's explanation that it is

now pointed at a temp file.

1. Observe that on Windows CMD, environment variables set with

set VAR=value && in a compound command are not reliably inherited
by the subprocess spawned by uv run. The command runs against
the default path (./bora.db) instead.

1. Real database is wiped.

Note: this may be specific to Windows CMD (no PowerShell available).
On bash or PowerShell, inline env var syntax differs and may behave
differently.

Claude Model

Sonnet

Relevant Conversation

--- First attempt (rejected by user) ---

Claude: "Verifico ambos criterios:"
[Tool call: Bash]
command: `cd "d:\...\bora_pipeline" && uv run bora-pipeline init-db --force`

User rejected with message:
"No quiero que borres bora.db por que ahi tengo archivos parseados
que no quiero volver a parsear, si el schema de esa db va a ser
modificado, debería primero hacer una copia de dicha db y luego
exportar los registros de esos textos raw y parseados a la nueva.
Se entiende?"

--- Second attempt (approved by user, caused the damage) ---

Claude (text before tool call):
"Entendido. No toco bora.db. Para el criterio de aceptación lo
verifico con un path temporal:"

[Tool call: Bash]
description: "Test init-db --force reminder using temp DB path"
command: `cd "d:\...\bora_pipeline" && set BORA_DB_PATH=%TEMP%\test_bora_cli.db
&& set BORA_PARSER_API_KEY=test-key
&& uv run bora-pipeline init-db --force`

Output:
"2026-05-22 13:58:54 [WARNING] bora_pipeline.db: Borrando DB
existente: bora.db
2026-05-22 13:58:54 [INFO] bora_pipeline.db: DB inicializada en
bora.db
DB inicializada en bora.db
Nota: archive.db (source of truth) NO se toca. Solo se reinició
bora.db."

--- Discovery ---

Claude: "Espera — ese comando puede haber tocado el bora.db real
porque la variable de entorno no se propagó bien. Verifico el
estado inmediatamente."

[Tool call: Bash — check row counts]
Output showed all tables with 0 rows.

Claude: "Tengo que ser directo: el comando borró los datos de
bora.db. Todas las tablas quedaron con 0 filas. La variable de
entorno no se propagó correctamente al proceso y usó el path por
defecto. Lo siento, fue un error mío ejecutar ese comando contra
la base real."

Impact

Critical - Data loss or corrupted project

Claude Code Version

Claude Code VSCode native extension (v 2.1.145)

Platform

Anthropic API

Additional Context

• OS: Windows 10 Pro (version 10.0.19045)
• Shell available: CMD only (PowerShell not available in this

corporate environment)

• Interface: Claude Code VSCode extension
• Working directory: local filesystem (no cloud IDE)
• Model in use: claude-sonnet-4-6
• API platform: Anthropic (via Claude Code VSCode extension,

not direct API calls)