git worktree remove fails with "Directory not empty" after docker-compose stack removal

Two separate mechanisms, one of which is invisible until you go looking for running containers.

1. The removal is not atomic, and the admin entry goes first.

git worktree remove deletes the administrative entry (.git/worktrees/<name>) before the recursive working-tree delete completes, then rmdirs the top directory last. So ANY failure in that window strands a directory that is no longer a registered worktree, which is why the retry says is not a working tree. Reproduced deterministically with an undeletable child (chmod 500 on a directory containing a file):

$ git worktree remove --force /tmp/lab/perm
error: failed to delete '/tmp/lab/perm': Permission denied   # exit 255
$ git worktree list --porcelain | grep -c /tmp/lab/perm
0                       # already unregistered, while .git and tracked files remain on disk

Note what survived there: .git, .gitignore, and tracked src/f.txt. git aborts the walk on first error, so the leftovers are NOT limited to whatever caused the failure.

--force only overrides the refusal to remove a dirty or locked worktree. It is not rm -rf, and (contrary to a common assumption) it is also not shy about ignored files: it deletes them.

2. The Directory not empty trigger is live bind mounts, not ignored files.

Containers from that worktree's Compose project were still running, with bind mounts whose source paths point into the worktree. Docker Desktop's file-sharing layer recreates a missing bind-mount source as an empty directory, so as git deletes the tree the daemon races it and re-creates the mount sources. Those recreated empty directories are what make the final rmdir fail with ENOTEMPTY.

The tell-tale signature: the leftover directories correspond exactly to the volumes: source paths in your compose file, and any source that is a regular file in a healthy checkout comes back as a directory (- ./config.stage.toml:/app/config.stage.toml yields config.stage.toml/). That is also why find shows zero files: they are freshly minted empty stubs, not residue.

Confirm before assuming the worktree is disposable, by mount source rather than by project name:

docker ps -a --format '{{.ID}} {{.Names}}' | while read id name; do
  docker inspect "$id" --format '{{range .Mounts}}{{.Source}}{{"\n"}}{{end}}' \
    | grep -q /path/to/wt && echo "$name"
done

In my case that printed nine containers, five still running, with a Postgres among them happily serving from a data directory whose inodes had just been unlinked. Teardown works by project name alone, without the (now deleted) compose file or working directory:

docker compose -p <project> down -v --remove-orphans
git worktree prune -v
rm -rf /path/to/wt

Why the stack was orphaned in the first place (the transferable trap): the wrapper CLI decided whether to run docker compose down based on a worktree "index" parsed out of the worktree's .env (WORKTREE_INDEX=, with a legacy fallback regex on COMPOSE_PROJECT_NAME=<prefix>-wt(\d+)). That .env had been generated by an older version whose project name was a branch slug and which did not yet emit the index key, so both probes missed, the index came back None, and the Docker teardown was silently skipped while the directory removal went ahead. Derive the project from COMPOSE_PROJECT_NAME directly, or discover it from container labels (docker ps --filter label=com.docker.compose.project=...), and never gate destructive cleanup on an optional metadata field that older generations of your own tooling did not write.

Practical checklist before removing a worktree that ever ran containers: stop the stack by project name; verify no container still mounts the path; use git status --porcelain --ignored if you want the real precondition; and wrap git worktree remove so a non-zero exit falls through to verify-then-rm -rf plus git worktree prune, because the worktree is already unregistered by then.