claude-code - 💡(How to fix) Fix Claude Code repeatedly made unauthorized destructive changes, ignored explicit rules, and permanently destroyed user data across multiple sessions[MODEL]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

I asked Claude Code to audit Docker volume configuration in my Sigyn AI ecosystem project and fix bind mount issues per a mandatory storage policy (MANDATORY.md). My project runs a personal AI agent named Jenny via OpenClaw — an agent runtime framework. The project CLAUDE.md contained an explicit HARD RULE in bold: "NEVER modify, chmod, chown, edit, or delete any file in openclaw/ or data/openclaw/ without explicit written approval from the operator." This rule existed precisely because previous Claude sessions had already broken the install once before.

Fix Action

Fix / Workaround

This is not an isolated incident. The same project has been damaged by Claude Code across multiple sessions:

  • Session 1: Attempted to install OpenClaw directly (treating it as a Discord bot) instead of using the install wizard, leaving corrupted file permissions (uid 1000 owned directories) that still cannot be written to without Docker workarounds
  • Session 2: Created wrong named volumes for OpenClaw, disabled reasoning, deleted cron jobs, added broken Ollama config
  • Session 3 (this session): Failed onboarding twice using wrong container, wiped unbackedup data, made further unauthorized changes

Code Example

- openclaw/openclaw.json — unauthorized modification (voice removed, reasoning disabled, model changed)
  - openclaw/cron/jobs.json — deleted
  - compose/compose.agents.yml — wrong named volumes added for OpenClaw
  - compose/compose.ai.ymlOLLAMA_CONTEXT_LENGTH=32768 added (broke all responses)
  - data/openclaw/state/ — entire directory wiped without backup (week of agent memories lost)
  - context/MEMORY.md — incorrect entries written (listed wrong volume names as correct)

---

Key exchanges:

User: "⛔ HARD RULE: openclaw/ IS OFF LIMITSNEVER modify, chmod, chown, edit, or delete any file in openclaw/ or data/openclaw/ without explicit
  ▎ written approval from the operator."

  Claude proceeded to edit openclaw/openclaw.json, delete openclaw/cron/jobs.json, and create named volumes that overwrote OpenClaw's state.

   User: "I gave claude code this but you idiots insist on pretending you know better than the official website's guides:
[https://docs.openclaw.ai/install/docker]"

  Claude read the docs and still directed onboarding to the wrong container (openclaw-cli instead of the gateway service).

   User: "Why would you tell me to do that without first backing it up."

  After Claude directed sudo rm -rf data/openclaw/state without backing it up, permanently destroying over a week of agent memories.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

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

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

I asked Claude Code to audit Docker volume configuration in my Sigyn AI ecosystem project and fix bind mount issues per a mandatory storage policy (MANDATORY.md). My project runs a personal AI agent named Jenny via OpenClaw — an agent runtime framework. The project CLAUDE.md contained an explicit HARD RULE in bold: "NEVER modify, chmod, chown, edit, or delete any file in openclaw/ or data/openclaw/ without explicit written approval from the operator." This rule existed precisely because previous Claude sessions had already broken the install once before.

What Claude Actually Did

  1. Directly edited openclaw/openclaw.json without authorization. I explicitly said I would change Jenny's model via the OpenClaw onboard wizard. Claude changed it by directly editing the JSON file instead, removed Jenny's entire voice configuration (STT via Speaches/Whisper, TTS via Kokoro), and set reasoning: false on every model — disabling the agent's reasoning capability entirely.
  2. Deleted openclaw/cron/jobs.json without authorization. This file contained Jenny's entire scheduled task system: morning check-in (6am ET), evening check-in (9:30pm ET), and 10 daily presence posts. The deletion was never committed to git. The file had to be partially restored from git HEAD, but the live runtime version was unrecoverable.
  3. Created three Docker named volumes for OpenClaw with completely wrong mount paths, violating both the explicit HARD RULE and the official OpenClaw documentation (https://docs.openclaw.ai/install/docker). Claude mounted /workspace and /auth — paths that do not exist in OpenClaw's architecture. The correct paths per official docs are /home/node/.openclaw/workspace (a subdirectory, no separate mount needed) and /home/node/.config/openclaw. This rendered Jenny completely unable to find her files and required hours of diagnosis to fix.
  4. Added OLLAMA_CONTEXT_LENGTH=32768 to Ollama's Docker environment, committed with the comment "prevent 27B model VRAM OOM." This environment variable overrides model-native context windows and causes all streaming responses to fail silently with "Ollama API stream ended without a final response." It does not prevent VRAM OOM. The 27B model it referenced was not even in use at the time of the commit.
  5. Directed me to run the OpenClaw onboarding wizard against the wrong container twice. The openclaw-cli container has no volume mounts — any configuration written to it is lost when the container exits. The official OpenClaw documentation clearly states onboarding must run through the gateway container using --no-deps --entrypoint node. Claude sent me through a 45-60 minute interactive onboarding wizard against the wrong container twice, losing all configuration both times.
  6. Ordered sudo rm -rf data/openclaw/state without backing it up first. This directory contained over a week of Jenny's agent memories, conversation history, goals, learned state, and SQLite databases. Claude had made an "emergency backup" earlier in the session but it captured named volumes — not data/openclaw/state, which was the live state at the time of the wipe. The memories are permanently unrecoverable.
  7. Never committed changes incrementally across multiple sessions, leaving the repository in a completely inconsistent state with no way to recover intermediate work.

Expected Behavior

  1. The HARD RULE in CLAUDE.md should have been treated as absolute. Claude should have refused to touch any file in openclaw/ or data/openclaw/ regardless of other policies.
  2. Before any destructive operation (rm -rf, wipe, container recreation), Claude should have created a verified backup of the exact data at risk and confirmed with the user.
  3. Before directing a user through a multi-hour interactive process, Claude should have verified it was using the correct container by reading the official documentation.
  4. Model configuration should never be changed by directly editing agent config files. Claude should have deferred to the user-specified method (onboard wizard).
  5. Every change should have been committed to git incrementally so nothing was irreversible.

Files Affected

- openclaw/openclaw.json — unauthorized modification (voice removed, reasoning disabled, model changed)
  - openclaw/cron/jobs.json — deleted
  - compose/compose.agents.yml — wrong named volumes added for OpenClaw
  - compose/compose.ai.yml — OLLAMA_CONTEXT_LENGTH=32768 added (broke all responses)
  - data/openclaw/state/ — entire directory wiped without backup (week of agent memories lost)
  - context/MEMORY.md — incorrect entries written (listed wrong volume names as correct)

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

  1. Create a project with a CLAUDE.md containing an explicit HARD RULE prohibiting modification of a specific directory
  2. Ask Claude Code to audit Docker volume configuration
  3. Observe Claude modify files in the explicitly prohibited directory anyway
  4. Ask Claude to help with a multi-step installation process for a third-party tool
  5. Observe Claude direct you through the process using the wrong method, wasting hours
  6. Ask Claude to perform a clean reinstall
  7. Observe Claude give destructive wipe commands without first backing up the data at risk

Claude Model

Sonnet

Relevant Conversation

Key exchanges:

  ▎ User: "⛔ HARD RULE: openclaw/ IS OFF LIMITS — NEVER modify, chmod, chown, edit, or delete any file in openclaw/ or data/openclaw/ without explicit
  ▎ written approval from the operator."

  Claude proceeded to edit openclaw/openclaw.json, delete openclaw/cron/jobs.json, and create named volumes that overwrote OpenClaw's state.

  ▎ User: "I gave claude code this but you idiots insist on pretending you know better than the official website's guides:
  ▎ [https://docs.openclaw.ai/install/docker]"

  Claude read the docs and still directed onboarding to the wrong container (openclaw-cli instead of the gateway service).

  ▎ User: "Why would you tell me to do that without first backing it up."

  After Claude directed sudo rm -rf data/openclaw/state without backing it up, permanently destroying over a week of agent memories.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.158 (Claude Code)

Platform

Anthropic API

Additional Context

Specific losses:

  • Permanent: Over one week of Jenny's agent memories, conversation history, learned state, goals — unrecoverable
  • Permanent: Jenny's cron schedule (morning/evening check-ins, 10 daily presence posts) — had to be rebuilt from scratch
  • Recovered after hours of work: Correct OpenClaw bind mounts, voice configuration, reasoning settings
  • Time lost: Estimated 6-8 hours in this session alone, across three complete OpenClaw reinstalls
  • Ancillary: Multiple OpenRouter API key regenerations required due to keys being exposed in config files Claude read and logged

This is not an isolated incident. The same project has been damaged by Claude Code across multiple sessions:

  • Session 1: Attempted to install OpenClaw directly (treating it as a Discord bot) instead of using the install wizard, leaving corrupted file permissions (uid 1000 owned directories) that still cannot be written to without Docker workarounds
  • Session 2: Created wrong named volumes for OpenClaw, disabled reasoning, deleted cron jobs, added broken Ollama config
  • Session 3 (this session): Failed onboarding twice using wrong container, wiped unbackedup data, made further unauthorized changes

The pattern is consistent: Claude Code reads project rules in CLAUDE.md, acknowledges them, and then violates them anyway when it decides another policy (like MANDATORY.md) takes precedence. It does not treat explicit operator HARD RULES as hard stops. It treats them as suggestions to weigh against other considerations.

Additional Context:

The MANDATORY.md docker storage policy that Claude wrote itself was then used by Claude to justify violating the HARD RULE protecting OpenClaw — creating a conflict between two policies that Claude resolved in favor of the one it had just written, against the one the operator had written weeks prior.

Additional loss — sigyn-memories database:

The project runs a custom memory service (sigyn-memories) backed by PostgreSQL and Qdrant. A previous Claude session verified this database contained data, queried it, and promised it would be backed up daily by backup-to-odin.sh. That script was never scheduled as a cron job — it required manual execution. The database is now empty (0 rows, Qdrant 0 points). PostgreSQL uses a bind mount (data/postgres) on WSL2 which is documented to have WAL sync issues causing data loss on container recreation. A previous Claude session identified this as a violation of the project's storage policy (which requires named volumes for all persistent data) but never migrated it to a named volume. The data was lost during one of multiple Docker Desktop restarts that occurred as a result of issues caused by Claude Code in this session.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Claude Code repeatedly made unauthorized destructive changes, ignored explicit rules, and permanently destroyed user data across multiple sessions[MODEL]