[bug] Moving a workspace's git worktree breaks it permanently — no way to re-point worktreePath #6791

Summary

Superset persists a workspace's worktree path. If that worktree is relocated on disk with git worktree move — a normal, supported git operation — the workspace breaks, and there is no supported way to point it at the new location.

workspaces get exposes the stored path as worktreePath, but workspaces update accepts only --name, --task-id, and --clear-task. Nothing across create / delete / get / list / open / update can re-point an existing workspace.

Git itself stays healthy throughout: git worktree move updates all of git's own bookkeeping, and the worktree re-registers correctly in git worktree list. Only Superset's copy of the path goes stale.

Steps to reproduce

1. Create a Superset workspace on a project. It lands at <repo>/.worktrees/<session-id>/<slug>.
2. From the main checkout, relocate it:

   git worktree move <repo>/.worktrees/<session-id>/<slug> <repo>/<new-parent>/<slug>
   

3. Verify git is fine — git worktree list shows the worktree at its new path, and git operations inside it work normally.
4. The workspace is now broken in Superset, and no workspaces update flag repairs it.

Impact

The only recoveries are:

• move the worktree back to the path Superset recorded, which forfeits whatever the relocation was for; or
• delete and recreate the workspace, losing its Superset-side state (task links, terminal history).

This came up while migrating a repo's worktree convention from .worktrees/<name> to .claude/worktrees/<name>. Eleven hand-made worktrees relocated fine; the two that were Superset workspaces had to be moved back and are now the only ones off-convention.

It's a surprising asymmetry, because the workspace setup script is scrupulously path-agnostic — .superset/setup.sh derives everything from SUPERSET_ROOT_PATH and git rev-parse --show-toplevel. The workspace record itself is the one path-pinned piece.

Related

#6051 notes the desktop app can import an already-existing worktree (Project Settings → Import, backed by openExternalWorktree / importAllWorktrees) and asks for that on the CLI/MCP. That would help here, but it isn't quite the same thing: importing produces a new workspace from a worktree, whereas this is about an existing workspace whose directory moved and which should be repairable in place.

#6730 is adjacent — a workspace/worktree consistency failure on delete rather than on move.

Suggested fix

Either would resolve it:

• a --worktree-path option on workspaces update, or
• re-resolution by worktree/branch identity when the recorded path no longer exists — git can identify the worktree by branch via git worktree list --porcelain, so a stale path is recoverable without user input.

A warning at detection time ("this workspace's worktree is no longer at <path>") would also beat silent breakage.

Environment

• Superset CLI 1.22.0
• macOS (Darwin arm64)