Ghosthub 0.9.0 (118), bundled kwt cc53a84, macOS 26. The kwt on PATH is the bundled binary (same revision).
This is the removal-side counterpart of #180, which covers externally created worktrees not appearing: externally removed worktrees keep showing in the sidebar.
Steps:
- Ghosthub running, showing a registered project with two worktrees.
- From a terminal (not a Ghosthub-launched action), run
kwt remove -b <branch> for both worktrees. The worktrees had no tmux sessions.
git worktree list and kwt list immediately confirm both are gone.
Observed: the sidebar keeps both worktree rows. I found no explicit refresh action; kwt daemon restart (confirmed via kwt daemon status: new pid, new port) did not clear them, and quitting and relaunching Ghosthub did. I did not test whether an app-initiated worktree action on another project would trigger a refresh as a side effect.
Expected: worktree rows removed outside the app disappear without a relaunch — either automatically, or via an explicit refresh action. Since #184 asks for a refresh action for the tmux session inventory: if that lands, having it also re-scan the kwt project/worktree inventory would cover #180's case and this one with one control.
Ghosthub 0.9.0 (118), bundled kwt cc53a84, macOS 26. The
kwton PATH is the bundled binary (same revision).This is the removal-side counterpart of #180, which covers externally created worktrees not appearing: externally removed worktrees keep showing in the sidebar.
Steps:
kwt remove -b <branch>for both worktrees. The worktrees had no tmux sessions.git worktree listandkwt listimmediately confirm both are gone.Observed: the sidebar keeps both worktree rows. I found no explicit refresh action;
kwt daemon restart(confirmed viakwt daemon status: new pid, new port) did not clear them, and quitting and relaunching Ghosthub did. I did not test whether an app-initiated worktree action on another project would trigger a refresh as a side effect.Expected: worktree rows removed outside the app disappear without a relaunch — either automatically, or via an explicit refresh action. Since #184 asks for a refresh action for the tmux session inventory: if that lands, having it also re-scan the kwt project/worktree inventory would cover #180's case and this one with one control.