Windows codex-retention.ps1 hardcodes repository path for git worktree prune

Summary

I use codex-retention.ps1 to prevent local .codex/sessions growth. On my machine this helper grew to +100GB until I started pruning monthly. During cleanup I found a safety issue: the script hardcodes the prune target to C:\Users\User\Projects\agenthost-internal.

If the script is shared across machines (or users), this can:

• run prune against a nonexistent or wrong repo,
• silently do nothing in setups where that path differs,
• or, worse, prune the wrong repo if another checkout exists at that hardcoded path.

This is risky on machines with multiple Codex worktrees and can lead to unexpected git state drift.

Repro

1. Run powershell -NoProfile -File C:\Users\User\Scripts\codex-retention.ps1 on a Windows machine where the hardcoded path is not the current repo.
2. If cleanup deletes old files, script reaches git worktree prune phase.
3. It still executes against the hardcoded root path rather than the active repo.

Expected

Retention utility should prune worktrees only for the repo it actually operated on (or an explicitly passed repo root), not a fixed absolute path.

Observed

Prune root is hardcoded:

• git -C C:\Users\User\Projects\agenthost-internal ... (older behavior)
• not derived from active location or invocation context.

Impact

• Inconsistent cleanup behavior across users/machines
• Potential wrong-repo prune operations
• Increased operational risk after long sessions where retention script is used manually (exactly when disk pressure is highest)

Fix (suggested)

• Resolve repo root from current location (git rev-parse --show-toplevel) with safe fallback.
• Validate detected root contains .git before running git worktree prune.
• Keep behavior opt-in / no-op if no valid repo root is detected.
• Optionally accept an explicit -WorktreePruneRoot parameter.

I implemented this safely in local workaround and can share patch details if useful. The rest of cleanup logic was unchanged.

Locate codex-retention.ps1 and trace the git worktree prune command reached after cleanup. Start by checking how the script determines its active location, then verify the prune target is derived safely or explicitly supplied and that invalid roots become a no-op. Reproduce with the documented PowerShell invocation on a machine without the hardcoded path.