Delete worktree failures are hard to understand and share

[VooDisss]

App Variant

Electron

Operating System & Version

Windows 11

Issue Summary

When deleting a worktree fails, CodeNomad currently makes the failure harder to understand and harder to share than it needs to be.

Steps to Reproduce

1. Open a workspace that has one or more non-root worktrees.
2. Open the worktree selector.
3. Try to delete a worktree that will fail to delete.
4. Common repro cases include:
   • the worktree contains modified or untracked files
   • another terminal, editor, watcher, or process is using the worktree directory
   • the directory is locked or access is denied on Windows
5. Observe how the failure is presented in the UI.

Expected Behavior

• The delete dialog should remain the primary place where the failure is explained.
• The user should see a short human-readable explanation before raw backend or git output.
• The UI should identify the likely cause when it can, such as:
  • local changes
  • another process is using the worktree
  • permission denied
  • worktree not found
• The UI should suggest the next action, such as:
  • enable Force delete to discard changes
  • close terminals, editors, or background processes and retry
• The raw error should remain visible and easy to copy for debugging.
• A sanitized copy option should be available so users can share failures without manually redacting machine-local paths.

Actual Behavior

• The failure path is too close to raw implementation detail.
• The error is not summarized in plain language first.
• The user must interpret raw backend or git output to understand what happened.
• Sharing the failure is cumbersome when the message includes machine-local paths.
• The delete dialog is not doing enough diagnostic work for a destructive action that commonly fails for understandable reasons.

Why this matters

• Delete-worktree failures are common and usually not mysterious once categorized correctly.
• Users should not need to parse JSON-ish backend output or raw git stderr to decide what to do next.
• A destructive action deserves stable, copyable, contextual error handling instead of minimal failure presentation.
• Better failure UX reduces support overhead and makes bug reports more actionable.

Suggested Solution

Update the delete-worktree modal so it becomes the canonical place for failure diagnostics:

1. Keep the failure inline in the modal.
2. Show a short summary in plain language.
3. Show a likely-cause label derived from known git/backend error patterns.
4. Show a suggested next step.
5. Keep the raw error visible below for debugging.
6. Add both raw and sanitized copy actions.

Example messaging

• Summary: Git refused to delete this worktree because it has modified or untracked files.
• Likely cause: Local changes
• Suggested next step: Enable Force delete if you want to discard local changes, or clean the worktree and try again.

Logs & Screenshots

Example raw failure text observed in practice:

{"error":"fatal: 'C:/.../worktree-checks' contains modified or untracked files, use --force to delete it"}

Additional Context

• This problem is especially noticeable on Windows, where directory locking and access-denied failures are common.
• The failure UI should not assume a PR already exists; this issue should stand on its own as a UX bug report and implementation request.