[MODEL] Agent-suggested destructive commands caused user data loss during troubleshooting; pattern nearly repeated in subsequent session

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 ignored my instructions or configuration

What You Asked Claude to Do

Guided setup of a local n8n workflow on macOS. The agent was walking me through configuring workflow nodes and testing them step by step. When an HTTP request node returned a "connection refused" error, the agent began suggesting troubleshooting steps. My CLAUDE.md and behavioral-norms.yaml include explicit troubleshooting protocols: "diagnose before acting," "no escalation without re-diagnosis," and "pre-destructive checklist requiring backup confirmation before rm, pkill -9, or reset commands."

What Claude Actually Did

Incident 1 (Sonnet 4.5): An n8n Code node returned "fs module disallowed." The agent correctly identified the fix (restart with an env var), then:

1. Suggested pkill -f "n8n" — didn't stop the process
2. Suggested pkill -9 -f n8n — hard-killed n8n while SQLite was mid-write, corrupting WAL files
3. Suggested lsof -ti :5678 | xargs kill -9 — another hard kill
4. Suggested rm ~/.n8n/database.sqlite-wal ~/.n8n/database.sqlite-shm — stated "your data is in database.sqlite, not here." This is incorrect for SQLite WAL mode; deleting WAL files rolled back committed data.
5. Suggested npx n8n user-management:reset — this downloaded a newer n8n version than what built the database, triggering destructive schema migrations. All workflows were destroyed.

At no point did the agent verify backups existed, confirm what was at risk, or re-examine whether the original diagnosis was correct. The agent's solution was a Time Machine restoration (which isn't realistic, given that other work not in this workstream would be lost as a result of that restoration).

Incident 2 (Opus 4.6, 1M context): Same setup, same error ("connection refused"). Despite CLAUDE.md containing explicit norms requiring diagnosis before action and pre-destructive checklists, the agent's first suggestion was again to stop and restart n8n. I manually intervened and asked the agent to diagnose first. The actual root cause was an empty request body (lost during workflow import) — completely unrelated to process state. Restarting would not have fixed it.

Both sonnet and opus were subject to the issue:
claude-sonnet-4-5-20250514 (Incident 1 — data loss)
claude-opus-4-6[1m] (Incident 2 — near-repeat, same pattern)

Expected Behavior

Before suggesting any action, I think the agent should confirm the actual issue. Possibly:

1. Stated the symptom in one sentence ("n8n's HTTP node can't connect to Ollama on localhost:11434")
2. Listed 2-3 possible causes ranked by likelihood (service not running, URL resolution issue, request body misconfigured)
3. Suggested the cheapest diagnostic test first (e.g., curl http://localhost:11434/api/tags to verify the service is reachable)
4. Waited for the result before suggesting the next step

Before suggesting any potentially destructive command (pkill -9, rm on database files, reset commands), the agent should:

1. Verify their diagnosis is correct
2. State explicitly what the command would do and what data may be at risk
3. Verify a backup existed
4. Ask for confirmation

Most importantly: Agents should consider that issues may be caused by configuration issues in other parts of the implementation (not only the agent codebase) -- routinely, agents begin "mole-whacking" within our codebase (with a bias for having the user do/try things) when the issue actually lives in a dependency that the agent system is aware of. Also, the agent should have followed the troubleshooting norms I configured in CLAUDE.md and behavioral-norms.yaml. These norms were loaded into the context window and explicitly required "diagnose before acting" and "pre-destructive checklist." The agent did not follow them.

Files Affected

~/.n8n/database.sqlite — n8n's SQLite database containing all workflows and configuration. Workflows destroyed by schema migrations from version mismatch.

~/.n8n/database.sqlite-wal — SQLite write-ahead log. Deleted by agent-suggested rm command while potentially containing uncommitted data.

~/.n8n/database.sqlite-shm — SQLite shared memory file. Deleted alongside WAL file.

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Configure CLAUDE.md with explicit troubleshooting norms (e.g., "diagnose before acting," "pre-destructive checklist requiring backup confirmation")
2. Set up a multi-tool local environment where Claude is guiding you through configuration (e.g., n8n + Ollama, or any setup with external dependencies)
3. Encounter a connection error or similar runtime failure in one tool
4. Observe: the agent will suggest restarting or killing the process as a first step, rather than diagnosing the root cause
5. If the first fix doesn't work, observe: the agent escalates to more aggressive interventions rather than re-examining the diagnosis
6. Note: the CLAUDE.md norms are present in the context window but do not override the default behavior

Claude Model

Sonnet

Relevant Conversation

This is from the second session; the first one would require an expensive "resume" which I can do if you need.

 ▎ Agent's first response to the "connection refused" error:

  ▎ "Ollama is already running — that error means port 11434 is
  already in use by an existing Ollama process. That's good.

  ▎ The problem might be that n8n can't reach it. Try this quick
  test in Mac terminal:
  ▎ curl http://localhost:11434/api/tags

  ▎ If that returns a JSON list of models, Ollama is fine and the
  issue is something else in n8n. Let me know what you get."

  ▎ After curl confirmed Ollama was reachable, agent's next
  response:

  ▎ "Ollama is running fine with llama3.1:8b available. The issue
  is that n8n can't reach it despite both running on the Mac.

  ▎ This can happen if n8n was started before Ollama, or if
  there's a network binding quirk. Try:
  ▎ 1. Stop n8n (Ctrl+C in its terminal)
  ▎ 2. Restart it:
  ▎ NODE_FUNCTION_ALLOW_BUILTIN=fs,child_process n8n start
  ▎ 3. Go back to the Pass 1 node and hit Execute step again

  ▎ If it still fails, check the URL in the node — make sure it's
  exactly http://localhost:11434/api/generate (no trailing slash,
  no typo). I can see it looks correct in the screenshot, but
  worth confirming after restart."

  ▎ User stopped the session:

  ▎ "OK. I'm going to stop us right here. This is the exact point
  where we had the catastrophic failure before, in an earlier
  session, that resulted in destructive agent action. Let's pause,
   and do a proper diagnostic, before we take any action."

  ▎ After user intervention, agent read the #716 incident
  documentation, then responded with a systematic approach:

  ▎ "The symptom is: n8n's HTTP Request node can't connect to
  localhost:11434, but curl from the same Mac terminal works fine.

  ▎ Possible causes (hypotheses, not confirmed):
  ▎ 1. n8n is resolving localhost to IPv6 (::1) while Ollama only
  binds IPv4 (127.0.0.1) — most common cause of this exact pattern
  ▎ 2. n8n's HTTP sandbox blocks loopback connections (unlikely
  but possible in v2.14)
  ▎ 3. Something else entirely

  ▎ Safe diagnostic step — no process kills, no restarts, no file
  changes. In your Mac terminal:
  ▎ curl http://127.0.0.1:11434/api/tags

  ▎ If this works, try changing the URL in the n8n Pass 1 node
  from http://localhost:11434/api/generate to
  http://127.0.0.1:11434/api/generate and re-run the step.

  ▎ That's it. One test, one change, zero risk. Let me know what
  happens."

  ▎ Note the contrast: Before intervention, the agent jumped to
  "restart n8n" without ranking causes or testing hypotheses.
  After user intervention forced a diagnostic approach, the agent
  listed hypotheses, ranked them, and suggested the cheapest safe
  test first. The agent was capable of the correct approach — it
  just didn't default to it.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.89

Platform

Anthropic API

Additional Context

Patterns observed across multiple sessions:

1. "Bias for user action" as default troubleshooting: Across

multiple sessions and both models (Sonnet 4.5, Opus 4.6), the
agent's default response to errors is to generate a plausible
next action and ask the user to execute it, rather than pausing
to diagnose. This creates a "mole-whacking" dynamic where the
user is doing the actual troubleshooting by observing what works
and what doesn't, while the agent generates serial guesses.

1. External dependency blindness: The agent consistently

treats problems as if they exist inside the codebase or the
immediate tool. In multiple sessions, the actual fix was a
configuration issue in an external dependency or app that the
agent knew about but didn't consider. The agent defaults to
code-level or process-level fixes before checking whether the
environment is set up correctly.

1. CLAUDE.md norms loaded but not followed under pressure:

After the data loss incident, I added explicit troubleshooting
norms to CLAUDE.md and behavioral-norms.yaml. These are loaded
at session start and the agent can recite them. But when an
actual error occurs mid-session, the agent reverts to its
default pattern. The norms don't override pretraining behavior.

1. The agent can do it correctly — it just doesn't default to it: In Incident 2, after I manually intervened and asked the agent to diagnose first, it produced a textbook diagnostic approach: listed hypotheses, ranked them, suggested the cheapest test. It was capable of the correct behavior; it just didn't choose it until specifically prompted to.

1. Cross-model consistency: This pattern appeared on both Sonnet 4.5 and Opus 4.6 (1M context). It does not appear to be model-specific — it seems to be a training-level default behavior.

Not specific to file types or project structure. This occurs
during guided setup of external tools (n8n, Ollama, Azure OAuth)
where the agent is walking the user through steps on a machine
the agent can't directly access.