Edit/Write tool leaves .tmp.<PID>.<hex> files after atomic rename

Summary

Editing or creating files via Claude Code's Edit/Write tool leaves <filename>.tmp.<PID>.<hex> residual files in the directory. These accumulate across sessions and require manual cleanup. Could you clarify whether this is intentional (transaction safety) or unintentional (cleanup bug), and confirm what cleanup approach is safe?

Reproduction

1. Open Claude Code session in any project
2. Use Edit tool to modify a file (e.g., ~/.claude/CLAUDE.md)
3. Inspect parent directory:

``bash
find <directory> -name '*.tmp.*'
``

1. Observed: residual file matching <filename>.tmp.<PID>.<hex> or <filename>.tmp.<hex> remains after the Edit call returns success
2. Example timestamps: actual file mtime 2026-05-14 19:14, residual file mtime 2026-05-14 19:13 (~1 min before, same session, never cleaned up)
3. Repeat across many sessions: residuals accumulate. One setup observed 412 residual files across ~/.claude/ after extended use (projects: 228, plans: 74, rules: 17, skills: 9, scripts: 2, .credentials.json.tmp.*: 3).

Environment

• Claude Code CLI: bundled (C:\Users\<user>\AppData\Roaming\Claude\claude-code\<version>\claude.exe, observed 2.1.138)
• OS: Windows 11 (Git Bash shell harness)
• File patterns (2 observed):
• <filename>.tmp.<PID>.<hex> — e.g., MEMORY.md.tmp.133200.e9386df7a3af (most files)
• <filename>.tmp.<hex> — e.g., .credentials.json.tmp.fecf8fbf (credentials file only, no PID segment)
• Affected directories: ~/.claude/projects/<hash>/memory/, ~/.claude/plans/, ~/.claude/rules/, ~/.claude/skills/, ~/.claude/scripts/, and ~/.claude/.credentials.json.tmp.*

Questions for clarification

1. Intent: Is the .tmp.<PID>.<hex> file an intentional artifact for atomic rename / transaction safety, or an unintentional cleanup miss after rename completion?
2. Atomicity guarantees: Does Edit/Write guarantee tmp → final rename is atomic? If so, is it safe for users to delete residual .tmp.* files matching the patterns above after the tool call returns?
3. Cleanup timing: For automation via PostToolUse hooks in .claude/settings.json, what is the recommended timing? Is find ... -mmin +5 -delete safe, or could it break in-progress transactions?
4. Schema change: An earlier observation in 2026-04-24 noted suffix format <timestamp_ms> (e.g., .tmp.12345.1714540800000); current 2026-05-18 observation shows suffix format <hex> (e.g., .tmp.133200.e9386df7a3af). Was this an intentional schema change, and if so, is the new suffix a UUID, random hex, or other identifier?

Workaround currently used

Manual find -delete invocation per session:

find ~/.claude -name '*.tmp.*' \
  \( -regex '.*\.tmp\.[0-9]+\.[a-f0-9]+$' -o -regex '.*\.tmp\.[a-f0-9]+$' \) \
  -delete 2>/dev/null

• Result: 0 residuals maintainable per session with manual discipline, but not automated by default.

Proposed solution (pending clarification)

If atomic-write semantics confirm safe tmp deletion after rename:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": { "tool_name": ["Edit", "Write"] },
        "command": "find ~/.claude -name '*.tmp.*' \( -regextype posix-extended -regex '.*\.tmp\.[0-9]+\.[a-f0-9]+$' -o -regex '.*\.tmp\.[a-f0-9]+$' \) -mmin +1 -delete 2>/dev/null"
      }
    ]
  }
}

(-mmin +1 to avoid deleting in-progress transactions; ~/.claude scope only to respect protected user directories.)

Impact

• Disk usage: ~5 KB-100 KB per residual × hundreds across long-running setups (observed ~108 KB for MEMORY.md residuals)
• Discoverability: residuals clutter ls/find results during legitimate file searches
• Manual cleanup overhead: Cleanup loops add overhead per session if not automated

References

• Internal procedure documenting manual cleanup pattern + safety regex
• Pattern first observed 2026-04-24 (then <PID>.<timestamp_ms> suffix); current 2026-05-18 observation shows <PID>.<hex> suffix (schema appears to have changed)

Thank you for clarification!