[Bug]: Status dot stuck on green "Running Tool" while session is actually waiting for approval (no notification)

[raphapizzi]

What happened?

A Claude Code session that is waiting on an approval prompt (Do you want to proceed? with options 1/2/3) renders with the green pulsing "Running Tool" status dot — both on the tab and in the sidebar — and no attention-bell notification fires. The user has no UI signal that the agent has stopped working and now needs their input.

Expected: the dot should turn into the red attn ("Needs approval") state and the attention bell should surface a waitingForApproval event the moment Claude Code rewrites its pidfile to status: "waiting", waitingFor: "approve <Tool>".

Actual: the dot stays green indefinitely. Switching to the tab and back does not refresh it. Restarting DPlex does correct the status (because the initial scanAll re-reads the pidfile), confirming the on-disk state is correct.

Steps to reproduce

1. Start a Claude Code session inside DPlex (claude CLI).
2. Ask the agent to do something that triggers a Bash tool call requiring approval (anything not in the "Yes, don't ask again" list).
3. Wait for the approval prompt to appear in the terminal.
4. Observe the tab's status dot and the sidebar — both stay green pulsing.
5. Observe the attention bell — no badge increment, no notification.

Screenshot

DPlex version

0.15.0 (also reproduces on 0.13.0)

Operating system

macOS

OS version

macOS 15 / Darwin 24.6.0

AI provider involved

Claude Code

Logs or console output

The pidfile on disk has the correct state, but the in-memory registry snapshot is stale:

$ cat ~/.claude/sessions/<pid>.json
{
  "pid": 63996,
  "sessionId": "0d09800d-17fa-43e0-ad79-85c2fb827067",
  "cwd": "/Users/raphaelpizzi/nexus-with-report",
  "status": "waiting",
  "waitingFor": "approve Bash",
  "updatedAt": 1778617553212
}

Root cause analysis

ClaudePidfileRegistry (in src/main/services/providers/claudePidfileRegistry.ts) is purely event-driven — it relies entirely on a single fs.watch() watcher attached to ~/.claude/sessions/ and never polls. On macOS, fs.watch is backed by FSEvents, which is known to coalesce or drop notifications for in-place rewrites of small files — exactly how Claude Code mutates its pidfile when transitioning from status: "busy" to status: "waiting".

When the event is dropped:

• refreshFile never fires → snapshot stays at status: "busy"
• mapPidfileStatus keeps returning executingTool → StatusDot shows the green pulsing dot
• attentionService.ingestSessionUpdate never receives the transition into awaitingApproval → no event in the inbox, no notification, badge unchanged

Both symptoms (stuck status dot + missing notification) share this single root cause.

Related but distinct from #59 / #60 (those address AttentionBellButton click-handling once the event is in the inbox; this issue is about the event never landing in the inbox in the first place).

Proposed fix

Add a periodic polling rescan (~2s) as a safety net alongside fs.watch. Polling guarantees eventual consistency when the watcher drops events, while fs.watch continues to provide low-latency updates in the common case.

I've prepared a PR with this fix plus regression tests — incoming.

Before submitting

• I searched existing issues and this is not a duplicate.
• I am running the latest released version (or noted the version above).

[Ron537]

Thanks so much for the detailed write-up and for offering a PR — really appreciate the care you're putting into this 🙏 The on-disk-vs-in-memory divergence you described is definitely real (the "restart fixes it" detail nails that down), so something here needs attention.

Before we settle on a fix though, could we get a bit more evidence that fs.watch is actually dropping the event? The "FSEvents coalesces / drops in-place rewrites" behavior is often cited but I'd like to confirm it's what's happening here rather than something else in our own code (the 200ms debounce, a verifyProcessIdentity race, or a stop/start generation race could all produce the same symptom). A quick way to capture this:

In src/main/services/providers/claudePidfileRegistry.ts, inside attachWatcher, log every raw event before the .json filter:

this.watcher = fs.watch(this.dir, { persistent: false }, (event, filename) => {
  console.log('[claude-watch]', event, filename, Date.now())
  // ...existing code
})

And log entry/exit of refreshFile with the parsed status/waitingFor. Then repro the bug and share the log around the busy→waiting transition. If we see zero callbacks for the transition write, the diagnosis is confirmed. If we see a callback but no state update, the bug is on our side and polling would be masking it rather than fixing it.

On the fix itself — a flat 2s rescan of the whole directory is something we'd want to avoid as-is, mainly for perf reasons:

• It runs even when there are zero active sessions / zero subscribers.
• A full readdir + readFile + JSON.parse per pidfile every 2s scales with stale files, not active ones.
• It adds up to 2s of latency to the common case where the watcher works fine.
• It also tends to hide the underlying bug rather than fix it.

If we do add a polling safety net, we'd want it scoped: only running while there are subscribers, only touching the specific PIDs already in this.snapshots, and ideally only kicking in when the watcher has been silent for a while or when a window/tab regains focus. That covers the "I came back and the dot is wrong" case for almost free, without a background timer churning forever.

We also briefly considered swapping fs.watch for chokidar here — its awaitWriteFinish + atomic options are designed for exactly the pidfile-rewrite pattern, and it normalizes a lot of cross-platform watcher quirks. It might be the right long-term direction, but probably as its own separate refactor rather than bundled into this fix.

Would you be up for grabbing those logs first? Once we know which path is failing we can land the minimal correct fix together. Thanks again for jumping on this — contributions like this are exactly what keeps the project healthy ❤️