Potential data loss: Files not listed in rm command were deleted

Bug Description

During a PDF compression session, files that were NOT explicitly listed in an rm -f command were deleted. This resulted in data loss of the original file and a successfully created compressed file.

Environment

• macOS Darwin 25.2.0 (arm64)
• Claude Code CLI (Opus 4.5)
• Shell: zsh (user), but Claude Code uses /bin/bash subshell

What Happened

1. User had a 194MB PDF file: original_document.pdf
2. Successfully compressed to 37MB as document_cpdf4.pdf using cpdf
3. User requested cleanup of temporary files
4. I ran rm -f with explicit file paths (no wildcards):

rm -f /Users/.../document_step1.pdf \
  /Users/.../document_cpdf.pdf \
  /Users/.../document_cpdf2.pdf \
  /Users/.../document_cpdf3.pdf \
  /Users/.../document_cpdf5.pdf \
  /Users/.../document_mutool.pdf \
  /Users/.../document_mutool2.pdf \
  "/Users/.../original_document_compressed.pdf" \
  "/Users/.../original_document_compressed2.pdf" \
  "/Users/.../original_document_compressed3.pdf" \
  "/Users/.../original_document_compressed4.pdf"

1. After execution, these files were ALSO deleted (but NOT in the command):

• document_cpdf4.pdf (the successful output)
• original_document.pdf (the original)

Investigation

• No rm alias exists (whence -v rm shows /bin/rm)
• No extended glob options enabled
• No iCloud sync on Downloads folder
• Files not in Trash
• Spotlight and mdfind confirm files no longer exist
• The command used backslash line continuations and quoted paths with spaces

Possible Cause

According to Claude Code documentation research:

"Claude's tool input must not contain literal newlines in the JSON command field, as tool calls are single-line strings" "If Claude generates a command with embedded newlines, the command + '\n' injection may split it incorrectly"

The multi-line rm command with backslash continuations may have been parsed incorrectly by Claude Code's bash execution mechanism.

Earlier Session Issues

Earlier in the session, there were parsing anomalies:

0head: echo: No such file or directory
head: Text-Wörter:: No such file or directory

This suggests command parsing was already problematic.

Impact

• Complete data loss of original file (194MB)
• Complete data loss of successfully compressed file (37MB)
• No recovery possible (no Time Machine)

Expected Behavior

rm -f with explicit file paths should ONLY delete the files explicitly listed, never other files.

Suggested Fix

1. Validate that multi-line commands with backslash continuations are correctly preserved when sent to bash subshell
2. Consider adding a safety check/confirmation for rm commands
3. Log actual commands sent to bash for debugging