codex - 💡(How to fix) Fix Codex Desktop cleanup should not treat no-PR untracked worktrees as abandoned

Summary

Codex Desktop cleanup should not treat no PR plus only untracked files as an abandoned git worktree signal.

A cross-tool cleanup session removed another active agent's worktree by running git worktree remove --force against a worktree that had no open PR yet and contained only untracked generated/artifact files. That shape is normal for pre-commit work. The active session had an external work_in_progress record, but the cleanup heuristic only considered local git/PR state.

Why this matters

In multi-agent local development, worktree ownership is shared operational state. A worktree can be active even when:

• no PR exists yet;
• no commit exists yet;
• only untracked files exist;
• the branch name belongs to another tool's namespace.

A single-force worktree removal can destroy active pre-commit work if the worktree is not git-locked.

Reproduction shape

1. Tool A creates a git worktree for active work.
2. Tool A is still pre-commit/pre-PR and has only untracked files.
3. Tool B performs cleanup from the primary checkout.
4. Tool B sees no PR and only untracked files and runs git worktree remove --force <path>.
5. Tool A's active worktree is removed.

Requested behavior

Before destructive worktree cleanup, Codex Desktop should:

• respect git-native worktree locks and surface a clear warning instead of trying to remove locked worktrees;
• avoid treating no PR or only untracked files as sufficient abandoned-work signals;
• prefer cleanup only for worktrees Codex created itself, or require an explicit owner/prefix match;
• ideally expose/consult an ownership or active-session marker before removing worktrees created outside the current Codex session;
• avoid git worktree remove --force for cross-tool worktrees unless the user explicitly confirms the exact path and loss risk.

Local mitigation we added

We changed our repo workflow to lock active worktrees with git worktree lock, route cross-tool cleanup through a lock-aware cleanup script, and retire an unreliable local launchd reaper. This reduces local risk, but the product heuristic is still risky for repos without that mitigation.