Claude code hooks not setup correctly

Open
  • Is something wrong?
#2,916 13 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #2917 by @worktrunk-bot — closed without merging

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Domain
cli, devtools

Research direction

Start with hooks/hooks.json and trace how its Claude Code events drive the 🤖/💬 markers shown by wt list. Check the linked pull request (#2917) and the issue discussion before making changes, since work has already been proposed. Done means the markers distinguish active work from waiting as described, without treating a finished subagent as an idle main agent.

Written by the indexing model from the issue text.

Description

Sometimes the 🤖/💬 markers report incorrect status.

This is mostly Claude's own analysis, slightly edited:

The plugin (hooks/hooks.json) drives the 🤖/💬 markers in wt list entirely from three Claude Code events:

│ Claude Code event │ Action │ Fires when │
│ UserPromptSubmit │ set 🤖 (working) │ you submit a new prompt │
│ Notification │ set 💬 (waiting) │ a permission prompt shows, or the session is idle 60s │
│ SessionEnd │ clear │ session ends │

Root cause of the stuck 💬

Nothing ever flips the marker back to 🤖 except a brand-new user prompt. The state machine is one-way:

  • Notification fires mid-work — most commonly a tool-permission prompt ("Claude needs permission to use Bash"), but also the 60s idle ping.
  • That sets 💬.
  • You approve, the agent resumes and keeps working through a long tool sequence…
  • …but no event resets 🤖. UserPromptSubmit only fires on a new human prompt, not on permission approval or continued tool use.

So any session that hit a permission/notification prompt and then kept working shows 💬 ("waiting") while actually working — exactly your two sessions. It's a missing transition, not unreliable hooks.

The fix

Add two hooks

│ Event │ Action │ Why │
│ PostToolUse │ set 🤖 │ re-asserts "working" after every tool — corrects a stale 💬 the moment work resumes (e.g. after a permission grant) │
│ Stop │ set 💬 │ the accurate "waiting for input" signal — fires exactly when the turn ends │

Net behavior: 💬 correctly shows only while genuinely blocked (permission prompt wait, or turn finished). The instant a tool runs again, it returns to 🤖. I'd deliberately not hook SubagentStop (subagent finishing doesn't mean the main agent is idle).

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.