gt abort

reset unrelated active worktrees before failing Graphite CLI 1.8.6, Linux, multiple concurrent worktrees sharing one Git repository. While abandoning a conflicted restack, an agent ran:

gt abort --force --no-interactive

The debug log shows: 1.

git rebase --abort

succeeded. 2. Graphite issued seven successful

git -C <other-worktree> reset -q --mixed <older-sha> --

commands across unrelated active worktrees. 3. It then failed because it attempted to delete a branch checked out in another worktree. Those resets moved branch tips and indexes backward while preserving working files. Consequently, newer committed work appeared as uncommitted changes against older revisions. Pushed PR revisions were unaffected. This appears consistent with restoring a broader saved repository state, but we haven’t established why unrelated concurrent work was included. Is this expected behavior for

abort --force

? Should restoration be limited to refs changed by the interrupted operation, detect intervening changes, and validate worktree constraints before performing resets? We have debug logs confirming the sequence and can provide sanitized excerpts.

feel free to investigate it if you think it's important