claude-code - 💡(How to fix) Fix [BUG] Write tool silently auto-creates new top-level dotfile directories in $HOME on a typo'd path "knife 🔪" - scary word, not your average "smoking gun" [1 comments, 2 participants]

Screenshot

Summary

When the Write tool receives a file_path with intermediate directories that don't exist, it silently creates them — including brand-new top-level dotfile directories under $HOME. No confirmation gate, no warning, no diff against existing filesystem state. A single mis-emitted token in a path argument can spawn an arbitrary directory tree in the user's home folder.

This is independent of the model emitting the wrong path in the first place. The model slip is a separate, non-reproducible concern; this issue is about the tool surface being the last line of defense and not catching it.

Concrete incident (2026-05-18)

Working in Claude Code with Opus 4.7 (claude-opus-4-7[1m]), I asked the agent to transfer memory between two Claude project dirs on the same machine.

It ran a correct mkdir:

mkdir -p /Users/radif/.claude/projects/-Users-radif-Ello-learn-1/memory

Then on the immediately following Write tool call, the path arrived as:

/Users/radif/.knife/projects/-Users-radif-Ello-learn-1/memory/project_egm_1741_screen_music.md

.knife instead of .claude. The Write tool returned File created successfully — no flag that .knife/ was a brand-new top-level dotfile directory under $HOME. The agent caught it on its next output and cleaned up with rm -rf /Users/radif/.knife, which also went through with no gate.

The agent's mkdir line one tool call earlier was the correct .claude path, so this wasn't a persistent confusion — it was a single-token slip within the same turn.

Reproduction (deterministic, independent of the model)

Manually call the Write tool with a path like:

file_path: /Users/<you>/.deliberatelynew/x.md
content:   "hi"

→ The file is created. The intermediate .deliberatelynew/ directory is silently created in your home folder. No prompt, no warning, no audit trail beyond the success message.

Why it matters

• Path-component slips are a real failure mode in current LLMs — adjacent reports: #25402 (home directory misspelled), #17354 (literal ~/ directory created), #21865 (writes to /home/claude/). Each describes a different which path was emitted; none addresses the tool gate that let it through.
• "Brand-new top-level entry directly under $HOME, especially dotfile-prefixed" is a small, well-defined class of action that's almost never intentional from an AI agent in the middle of an unrelated edit session.
• Worst-case scenarios beyond this incident: a typo'd path overwrites a real dotfile config (e.g. .aws, .ssh, .gnupg near-misses) by happening to collide; or planted files in unintended config dirs get later read by other tools.

Suggested fix

Add a confirmation gate matching the existing permission-prompt pattern, fired when Write would materialize a previously-non-existent top-level entry directly under $HOME, especially one beginning with .. Same gate would also catch the related literal-~/ case in #17354.

Severity

Low-impact in this specific incident (one stray file, one easy rm -rf cleanup, no data loss). The underlying class of risk is broader: a silent filesystem write driven by a single mis-emitted token, with no surface that distinguishes "intended new top-level dotfile dir" from "typo'd new top-level dotfile dir."

Forensic dump

Full play-by-play of the incident (exact tool calls, observations, what was and wasn't verified) is preserved at the reporter's end and can be shared if useful.

Reporter context: Opus 4.7 (1M context), macOS, Claude Code CLI. Conversation was ~30k+ tokens deep into an unrelated design discussion (a Linear ticket about Flutter background music) when the typo happened.