Bash tool: newline characters in command string treated as spaces, causing rm -rf to delete unintended directories

Resolved 💬 3 comments Opened Feb 9, 2026 by 1mperatrica Closed Mar 9, 2026

Bug Report

Summary

When Claude Code sends a multiline command to the Bash tool, the \n characters in the command string are sometimes stripped or converted to spaces instead of being treated as newlines. This caused rm -rf to receive an unintended directory path as an argument, permanently deleting an entire project directory (~13,000 lines of code, 65 files).

Environment

  • Claude Code version: 2.1.34
  • OS: macOS (Apple Silicon)
  • Shell: zsh
  • Date: 2026-02-09

Steps to Reproduce

Claude generated this Bash command:

rm -rf /Users/user/project/apps/ui/.next/dev/cache
cd /Users/user/project && npx next dev apps/ui --port 3010 --no-turbopack &
sleep 12
echo "=== STATUS ==="
ps aux | grep next-server | grep -v grep

The JSON payload contained proper \n between lines:

"command": "rm -rf /Users/user/project/apps/ui/.next/dev/cache\ncd /Users/user/project && npx ..."

Expected Behavior

Each line should execute as a separate command:

  1. rm -rf .../cache — deletes only the cache directory
  2. cd /Users/user/project && npx next dev ... — starts dev server

Actual Behavior

The shell received the entire command as a single line with \n stripped/converted to spaces:

rm -rf /Users/user/project/apps/ui/.next/dev/cache cd /Users/user/project && npx next dev ...

This caused rm -rf to receive three arguments:

  1. .../apps/ui/.next/dev/cache ← intended
  2. cd ← literal string, silently ignored by rm -f
  3. /Users/user/projectENTIRE PROJECT DIRECTORY DELETED

Evidence

The shell output confirms single-line parsing:

sleep: invalid time interval: echo
sleep: invalid time interval: === STATUS ===
sleep: invalid time interval: ps

This proves sleep 12\necho "=== STATUS ==="\nps aux was parsed as sleep 12 echo === STATUS === ps aux — all on one line.

Impact

  • Severity: Critical — permanent data loss
  • The project was not yet in git, so no recovery was possible through version control
  • Recovery required extracting all Write/Edit operations from JSONL session transcripts (~3 hours of work)

Suggested Mitigations

  1. Validate rm -rf commands before execution — warn if rm -rf receives multiple path arguments, especially if one is a parent of another
  2. Ensure newlines are properly preserved when passing commands to the shell
  3. Never combine rm -rf with other commands using \n — always execute destructive commands in isolation
  4. Add a safety check: if rm -rf argument is a directory containing >N files, require confirmation

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗