/wt-diff doesn't list a worktree a Workflow agent edited in a background session

Open
#4,656 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
git, typescript
Domain
devtools, tooling

Research direction

Start with the diff module's tool.call hook, the part that records directories for Edit, Write and Bash calls, and its .catch handler, which currently drops errors silently. The first step is to log errors there and check whether the throw happens after await next(e), which would call next twice. Then add a case to tests/diff.test.tsx where a tool.call carries an agentId. Done when the workflow agent's worktree appears in /wt-diff in that test and a reproduction no longer loses it.

Written by the indexing model from the issue text.

Description

What happens

In a Claude Code background session (Claude Code 2.1.310), a Workflow tool run started one agent with isolation: "worktree". Over a couple of hours that agent edited files in its own worktree with Edit and Write and committed them. Afterwards, /wt-diff in the same session didn't list the agent's worktree. The pane showed only the session's own worktree, which by then had no changes left. The work became visible only after the commit was cherry-picked into the session's own worktree.

Expected

The module's header says it notes "each directory Edit, Write or NotebookEdit wrote a file in, and each one a Bash call ran in or changed a file in, subagents' calls included", so the workflow agent's worktree should be listed.

What I checked

I ran a headless session (claude -p --plugin-dir) with a small probe plugin whose tool.call hook logs each call and appends to a $.state value, and whose turn.complete hook logs that value. The session ran one Workflow agent and one Agent-tool subagent, each with isolation: "worktree", in a scratch repository. Each agent wrote a file with Write and ran pwd with Bash.

  • tool.call fired for both agents' Write and Bash calls. Each carried the agent's agentId, $.session.cwd() returned the agent's worktree, and file_path pointed inside it.
  • The values those hooks appended to $.state were all present when the main loop's turn.complete read them.

So in that setup every input the module depends on arrives, and I haven't reproduced the miss outside the original session. That session differed in four ways:

  • It was a daemon-backed background session, not claude -p.
  • It loaded the installed marketplace copy of the plugin (5b3bf92d0ffe), not --plugin-dir.
  • It ran for several hours, with a compaction before the workflow started.
  • The plugin's install record was updated twice during the session, to the same version.

Two things that would help pin it down

  • The tool.call hook ends in .catch(($, e, next) => next(e)), so any throw inside it drops the noted directories without a trace. Where the throw comes after the hook's own await next(e), it also calls next a second time. Logging the error there would make the next occurrence diagnosable.
  • tests/diff.test.tsx has no case where a tool.call carries an agentId, so the subagent and workflow-agent path isn't covered.

Seen on worktrunk 5b3bf92d0ffe.

This was written by Claude Code on behalf of max-sixty

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.