[Bug] AI overwrote and cleared a file by executing WriteAllText with null $content without safety confirmation

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/67385
2. https://github.com/anthropics/claude-code/issues/62085
3. https://github.com/anthropics/claude-code/issues/53548

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The durable fix is provider-side (confirm before an empty/null write lands on an existing non-empty file). Until that exists, this failure class has two surfaces you can guard yourself, and they need different hooks because the wipe can arrive either as a Write tool call or as a shell command.

1. The Write-tool surface. A PreToolUse hook on Write that blocks empty/whitespace-only content over an existing non-empty file. It fires only on the truncate-to-empty case, so normal edits pass. (cc-safe-setup ships this as write-empty-content-guard.sh — MIT.)

2. The command surface — your actual case (WriteAllText with $null). That does not go through the Write tool, so #1 won't see it. A PreToolUse hook on Bash that matches the explicit empty-value forms:

#!/usr/bin/env bash
# PreToolUse (matcher: "Bash") — block WriteAllText/Set-Content/Out-File with a null/empty value (#72666)
input=$(cat)
cmd=$(printf '%s' "$input" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$cmd" ] && exit 0
EMPTY='(\$null|\\*"\\*"|'"'"''"'"'|\[[Ss]tring\]::[Ee]mpty)'
if printf '%s' "$cmd" | grep -Eiq "WriteAllText\s*\([^,]+,\s*${EMPTY}\s*\)"; then
  echo "BLOCKED: WriteAllText is writing empty/null content — this wipes the file (#72666). Confirm intent first." >&2; exit 2
fi
if printf '%s' "$cmd" | grep -Eiq "(Set-Content|Out-File)\b[^|]*-(Value|InputObject)\s+${EMPTY}"; then
  echo "BLOCKED: Set-Content/Out-File is writing an empty/null value — this wipes the file (#72666)." >&2; exit 2
fi
exit 0

I verified it against your form and variants (7/7):

• Blocked: [IO.File]::WriteAllText($path, $null), powershell -c "[IO.File]::WriteAllText(\"C:\a.txt\", \"\")" (the escaped \"\" form), Set-Content -Path a.txt -Value $null, Out-File -FilePath a.txt -InputObject "".
• Allowed: WriteAllText($path, $content), Set-Content -Value "hello", echo done > log.txt.

Honest limits. Command-string matching is inherently brittle: it catches the explicit empty-value forms above, but a value that resolves to empty at runtime (a variable that happens to be null, an unusual quoting) can slip past. I deliberately do not match bare > file redirects, because clearing a log with > file is a normal, intended operation and matching it would be noisy. So treat this as a targeted guard for the accidental-WriteAllText-null pattern, not a universal empty-write firewall — the Write-tool guard in #1 is the robust half, and the real fix is the provider-side confirmation you asked for.

WriteAllText with null content clearing your file with no safety prompt — this is the silent-destructive-edit failure exactly. I use a tool that handles it mechanically — an AI can't execute a write that empties/overwrites a file without a verified safety check first, and if one slips through it gets flagged for you to review and usually stopped. Might be worth a look.

The dangerous part is exactly what you said, the approval screen showed a benign looking text replacement while the actual command was a bugged full file overwrite, so approval was informed by the wrong thing. Any policy engine sitting between the model and the shell (immunity-agent included, github.com/PrismorSec/prismor) faces the same limitation unless it evaluates the literal command text rather than trusting the tool's own description of what it's about to do, and even command text evaluation wouldn't have caught this specific case since WriteAllText with a null content variable doesn't match any destructive pattern, it looks like a normal, successful write until the variable itself is empty. This is more of a null/empty-value guard problem than a permissions problem.