Clean zero-change task cleanup partially removes worktree, then falsely reports uncommitted files

[rubybrowncoat]

Environment

• Codeg Desktop 0.30.0
• Windows
• Git linked-worktree task
• Merge strategy: squash
• Automatic processing and automatic merge: off
• Task result: zero tracked or untracked changes

Reproduction

1. Create and start a disposable task from a clean Git branch.
2. Have the task make no file changes and confirm git status is clean.
3. Let the task reach completion with Codeg showing “No changes vs the base yet”.
4. Click Complete, leave Delete the worktree after completing enabled, and confirm. It says Cleanup failed.
5. Click Retry cleanup after the cleanup error.

Expected

Codeg completes the zero-change task, removes its linked worktree and task branch, cleans its worktree-folder record, and reparents the conversation as applicable.

Actual

The task moves to Done, but Codeg displays:

validation error: the worktree was kept: it still holds uncommitted files. Remove them, then retry the cleanup.

The task made no changes, Codeg’s drawer showed no changes against the base, and Git status was clean before completion.

After the failed cleanup:

• git worktree list no longer contains the task worktree.
• The task directory remains, but is empty and no longer contains .git.
• The task branch remains at the original base commit.
• Codeg retains the worktree-folder record.
• The task records cleanup_state = failed.
• Retry cleanup returns the same error.

This is a partial teardown: Codeg removes the Git worktree registration and contents before reporting that the worktree was retained. The UI retry cannot finish cleanup because the directory is no longer a Git worktree.

Impact

A clean zero-change task cannot be fully cleaned up through Codeg’s UI. The error incorrectly reports uncommitted files, leaves an orphan branch/directory/folder record, and turns the retry action into a repeatable failure.
This also makes the dirty-worktree safety result ambiguous because clean and dirty states are not distinguished accurately.
No repository files were changed during the task. Automatic initialization or preflight may have created ignored build outputs, but the task had no tracked or ordinary untracked changes, and the remaining directory was empty after Codeg’s partial teardown.

Dirty-worktree control

A second disposable task intentionally created one untracked sentinel file. Codeg refused cleanup and correctly preserved the Git worktree registration, task branch, directory, and sentinel contents.

This confirms that dirty-worktree refusal itself works. The defect is specific to the zero-change cleanup path: a clean task was falsely classified as dirty after Codeg had already removed its worktree registration and contents.

[dawNotPoi]

I reproduced the retry loop on current main by simulating the Windows partial teardown: once Git registration and contents are gone but the empty directory remains, the status probe treats that Git error as uncommitted work and cleanup never gets another chance. I can fix this while preserving the safety boundary: only a readable, strictly empty shell will be treated as safe, and recovery will use a non-recursive empty-directory removal before pruning and deleting the unchanged branch. Non-empty or unreadable paths will continue to fail closed. I will include regressions for empty-shell recovery and sentinel-file preservation.