[Feature Request] Auto-cleanup empty .claude/.cc-writes/ directories after execution

Status Closed — not planned
Maintainer reply None cached
Activity 4 comments · opened Jul 12, 2026 · closed Sep 18, 2026

Can you please automatically clean up the empty .claude/.cc-writes/ directories you create in every project

View original on GitHub ↗

4 Comments

ogapo · 2 months ago

Adding a repro and an impact case, because this is worse than cosmetic — an empty .cc-writes dir in the wrong place hard-breaks a Cargo build, and the directories are invisible to git so nobody notices until it does.

Version: 2.1.220 · Platform: macOS (Darwin 25.5.0)

The directories are created relative to the shell's persisted cwd

Bash tool cwd persists between calls, so every directory a session cds into accumulates one. Minimal repro:

# call 1
mkdir -p /tmp/probe && cd /tmp/probe && ls -a
# → .  ..                      (clean)

# call 2 — no cd, cwd persisted from call 1
ls -a
# → .  ..  .claude             (.claude/.cc-writes/ now exists)

Note it appears on the second call, not the first. That suggests the staging dir is created during command setup using the cwd persisted from before the command runs — so a cd inside call N materializes the directory for call N+1. (Inference from the timing; I can't see the setup path.)

In one working session across two repos this left 9 of them, one per directory visited:

07-29 20:36  ./.claude/
07-31 15:11  ./caldera/.claude/
07-31 15:12  ./caldera/tools/proto-gen/.claude/
07-31 15:27  ./caldera/test/test-game/.claude/
07-31 15:29  ./caldera/test/test-game/content/server/gameplay/.claude/
08-02 08:14  ./content/protocol/.claude/
08-02 08:15  ./caldera/test/.claude/
08-02 08:15  ./caldera/test/test-game/content/server/gameplay/tests/.claude/
08-02 08:15  ./content/server/zones/etherial-plane/temple/.claude/

Impact: breaks Cargo workspaces that use glob members

A Cargo workspace declares members by glob:

[workspace]
members = ["apps/*", "tools/*", "test/integrations/*"]

When a staging dir lands directly under a glob root — a sibling of the real crates, not inside one — Cargo treats it as a workspace member and every single cargo invocation fails:

error: failed to load manifest for workspace member `/…/test/integrations/.claude`
referenced via `test/integrations/*` by workspace at `/…/Cargo.toml`
Caused by:
  failed to read `/…/test/integrations/.claude/Cargo.toml`
Caused by:
  No such file or directory (os error 2)

cargo build, check, clippy, test — all dead until the directory is removed. The error names .claude, which reads like a project-config problem rather than harness residue, so it costs a debugging cycle to trace.

The distinction matters: tools/proto-gen/.claude/ is harmless because it's inside a member. test/integrations/.claude/ is fatal because it's beside them. Which one you get depends purely on which directory the agent happened to cd into.

Why it goes unnoticed

Git does not track empty directories. These never appear in git status, and .gitignore cannot express "ignore this for tooling purposes" — so they silently accumulate across sessions and there's no in-repo signal until a build breaks.

Suggested fixes, in order of preference

  1. Don't put the staging dir in the working tree. Key it under the session dir or $TMPDIR and there's no problem to clean up. This also fixes #79945, where the sandbox's own write-deny on .claude/.cc-writes blocks ExitWorktree from removing a worktree.
  2. If it must live in the tree, create it once at the project root rather than cwd-relative — one predictable location instead of N.
  3. Failing both, remove it when empty at command completion (the original ask here).

Worth relabeling from enhancement to bug given the build breakage.

github-actions[bot] · 26 days ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

nikolajvonholck · 7 days ago

Still happens. Very frustrating, would love to see it fixed 🙏😊

marcindulak · 6 days ago

This issue was incorrectly closed by the github-actions bot, despite having reproduction steps and Claude version. This bot behavior is tracked in https://github.com/anthropics/claude-code/issues/87647. Consider upvoting that issue for visibilty, maybe the bot behavior gets fixed.