Branch markers outlive their worktree and branch, so a reused branch name inherits a stale 🤖/💬

Open
  • Is something wrong?
#4,683 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
git, rust
Domain
cli, tooling

Research direction

The marker is written in src/commands/config/state.rs around lines 932-933, and the only unset calls for worktrunk.state.* keys are the clear paths in that same file. Start by reading the wt remove code path and the helpers in src/git/repository/config.rs to see where branch deletion could clean up those keys. Done means a reproduction of the issue's steps no longer shows the old marker on a reused branch name, or wt list ignores markers whose branch is gone, with tests covering both.

Written by the indexing model from the issue text.

Description

Follow-up to #1733.

wt config state marker set stores the marker as worktrunk.state.<branch>.marker in the shared git config. Nothing removes that key when the worktree or the branch goes away, so a marker left behind by a session that never cleared it stays for good. #1733 was closed on the premise that "this goes away as soon as we remove the worktree, and even if we start a worktree with the same name, it gets reset". On 0.81.0 the key outlives both the worktree and the branch, and a new worktree on the same branch name shows the old marker.

Repro (0.81.0, macOS):

git init -q -b main /tmp/m && cd /tmp/m && git commit -q --allow-empty -m init
git worktree add -q -b feature ../m.feature
wt -C ../m.feature config state marker set 🤖
git worktree remove ../m.feature && git branch -D feature
git config --get-regexp '^worktrunk\.state\.'
# worktrunk.state.feature.marker {"marker":"🤖","set_at":...}   <- still there
git worktree add -q -b feature ../m.feature
wt list
# + feature      _ 🤖   <- the new worktree shows the old marker

This repro removes the worktree with plain git. I did not run wt remove. Reading the v0.81.0 source, though, nothing appears to unset the key on that path either. The marker is written at src/commands/config/state.rs:932-933. Every unset_config call on a worktrunk.state.* key is in src/commands/config/state.rs and runs only from wt config state ... clear (lines 1003, 1020, 1157, 1745, 1759, 1787, 1806). The other callers in src/git/repository/config.rs touch only worktrunk.history*, worktrunk.hints.* and worktrunk.default-branch.

In one repository that uses Claude Code worktrees heavily, git config --get-regexp 'worktrunk\.state\..*\.marker' listed 75 keys, and none of their branches still had a worktree. Its worktree branch names are deterministic (worktree-issue-<n>-<slug>), so a reopened issue inherits whatever marker the last session left.

How markers get stranded in the first place: a Claude Code session whose working directory moves during a turn (EnterWorktree / ExitWorktree) can set 🤖 on one branch at UserPromptSubmit, then send Stop and SessionEnd to another branch. The plugin avoids that by pinning to CLAUDE_PROJECT_DIR (#3956). Hook setups that follow the payload's cwd do not, and killed sessions (#1733) do not either.

Suggestions, smallest first:

  1. Unset worktrunk.state.<branch>.marker (and arguably the whole worktrunk.state.<branch> section) when wt remove deletes the branch, or when it removes the branch's last worktree.
  2. Have wt list skip a marker whose branch no longer exists, or document wt config state marker clear --branch <b> / --all as the cleanup for this case.
  3. Optionally, a wt config state prune that removes worktrunk.state.* sections for branches that no longer exist.
Dominant language
Rust
Stars
8.8k
Forks
315
Avg merge
1d 6h
Merged PRs (30d)
204

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from max-sixty/worktrunk

All issues in max-sixty/worktrunk

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.