[BUG] The harness dirties every isolated worktree via .claude/settings.local.json, which permanently disqualifies it from auto-cleanup — a read-only agent still leaks a full checkout

Summary

The harness writes to .claude/settings.local.json inside each isolated worktree, which marks that worktree dirty. Automatic worktree cleanup only removes worktrees that finish with zero changes, and the periodic sweep skips any worktree holding changes.

Net effect: the harness dirties its own worktree, then declines to collect it. A completely read-only agent that writes nothing still leaks a full checkout, permanently.

Reproduction

Run any isolated background agent that gets a tool permission approved, let it finish, then inspect the worktrees it left behind:

git -C .claude/worktrees/agent-<id> status --porcelain

Sampling 8 agent worktrees on this machine:

7 of 8  →  1 dirty file, and it is  M .claude/settings.local.json
1 of 8  →  4 dirty files, one of which is  M .claude/settings.local.json

7 of 8 are dirty on exactly one file, and it is the file the harness itself writes. The agent contributed nothing to that dirty state.

Impact

• 53 agent-* worktrees / 134 worktrees total on this machine, against a configured cap of 15.
• Each is a full checkout. In this repository that is ~1.85 GB apiece, and the worktree directory currently holds ~130 GB / ~945,000 files — 94% of every file in the tree.
• Growth is one-directional: creation is automatic, cleanup never fires. +21 worktrees in a 23-hour window while investigating this.
• The 30-day cleanupPeriodDays sweep never collects them for the same reason.

Why this is worth a fix

At least 9 existing issues report this accumulation as a symptom (e.g. #55435 — 48 worktrees / 11 GB in 9 days, closed not planned; #57767 — Windows lock failures during cleanup; plus several reporting cleanup destroying real work when it does fire).

As far as I can find, none of them names this mechanism. The reports read as "worktrees pile up"; the cause is that the cleanup precondition (no changes) is invalidated by the harness's own write before any agent does anything.

Suggested fix

Either of these appears sufficient:

1. Exclude harness-authored files from the dirty check used by auto-removal and the periodic sweep — .claude/settings.local.json in particular.
2. Don't write the permission grant into the worktree. Persist approvals at the session or user scope rather than the isolated checkout.

A workaround exists for background sessions — "worktree.bgIsolation": "none" (v2.1.143+) — but it is undocumented (see #59580), disables isolation entirely rather than fixing the leak, and does not cover worktrees created by other paths.

Environment

• Claude Code 2.1.222 (behavior observed across 2.1.212 → 2.1.222)
• Windows 11