Every cleanup run reports working trees containing submodules cannot be moved or removed for the same worktree. The worktree is clean, its submodules are clean, and manual removal fails with the same message. This is pingdotgg/t3code#20355.
Why it happens
git worktree remove without --force refuses any worktree with initialised submodules. Not just dirty ones - all of them. git-worktree(1) says it plainly: "Unclean worktrees or ones with submodules can be removed with --force". A cleanup that omits --force on purpose, so git still refuses when a tracked edit lands after the last status check, therefore turns every submodule worktree into a permanent failure that repeats on each run.
The fix
Verify the tree yourself, then force it:
git -C <repo> status --short
git -C <repo> worktree remove --force <path>
If you script worktree cleanup, keep the explicit cleanliness check and pass --force after it, extending the check through git submodule foreach --recursive first when the tree has submodules - checking status and commits that are not on any remote, the same checks you already do on the superproject. The race guard survives, because the check runs right before the removal. Relying on remove to refuse is a real safety net for ordinary trees and no net at all for submodule trees, where the same refusal applies to a pristine checkout.
One side effect worth knowing. A run can remove other worktrees fine and fail on only the submodule one, while the failure toast shows just the first reason - the sweep continues past a failure even when the message reads like it stopped.