Skip to content

Add blue pulsing status indicator for permission-prompt waiting state#136

Open
simo787c wants to merge 3 commits into
mainfrom
add-status-for-active-chats-when-awaiting-input-e55
Open

Add blue pulsing status indicator for permission-prompt waiting state#136
simo787c wants to merge 3 commits into
mainfrom
add-status-for-active-chats-when-awaiting-input-e55

Conversation

@simo787c

@simo787c simo787c commented May 8, 2026

Copy link
Copy Markdown
Collaborator

Problem

When Claude Code shows a permission prompt (asking the user to approve a tool), the status indicator in the sidebar would briefly flash blue (the new waiting state) for ~2 seconds before reverting to orange/amber (busy). The user had no visual cue that Claude was blocked waiting for their input.

Two root causes:

1. Polling self-heal fired too aggressively on waiting state

ActivityMonitor's polling loop contained a self-heal that transitioned waiting → busy whenever child processes were detected:

if (activity.state === 'waiting' && hasChildren) {
  activity.state = 'busy';
  ...
}

The intent was to detect when the user approved a permission and Claude started a tool. But Claude's process can have child processes for many reasons while displaying the permission dialog (e.g. the Claude CLI's own subprocesses, or subprocesses from prior tool executions). On macOS/Linux, the poll runs every 2 seconds — exactly matching the symptom reported. On Windows it's 5 seconds, but the same false positive still occurs.

This self-heal was also redundant: when the user actually approves, PreToolUse fires → setToolStart → already transitions any state (including waiting) to busy. The polling check wasn't needed.

2. setWaitingForPermission and setError didn't cancel pending busy timers

A debounced busy transition (pendingBusyTimer) from UserPromptSubmit could fire and overwrite the waiting/error states after they were set, because only setIdle and setToolStart cancelled the pending timer.

Changes

  • ActivityMonitor.ts: Remove the waiting && hasChildren polling self-heal. Add pendingBusyTimer cancellation to setWaitingForPermission and setError to match the pattern already in setIdle and setToolStart.
  • LeftSidebar.tsx, MainContent.tsx, ProjectOverview.tsx: Change the waiting state indicator from static orange (bg-orange-500) to pulsing blue (bg-blue-400 status-pulse-waiting) — visually distinct from both idle (green) and busy (amber), and the pulse makes it more attention-grabbing.
  • index.css: Add @keyframes pulse-glow-waiting and .status-pulse-waiting — a slower, softer blue pulse (opacity fade + scale) to differentiate it from the amber busy pulse.

State transition safety

The waiting state now only exits via hooks:

  • User approvesPreToolUse fires → setToolStartbusy
  • User denies / Claude stopsStop hook → setIdleidle
  • User types a responseUserPromptSubmitsetBusybusy
  • Stuck state safety valve → 45-second childless timeout → idle

Yolo mode (auto-approve) is unaffected: when auto-approve is on, the permission_prompt Notification hook never fires and waiting state is never entered.

How to validate

  1. Open a task with a fresh terminal (no existing tool approvals).
  2. Ask Claude to run a bash command it hasn't been approved to run yet (e.g. run ls -la).
  3. When the permission dialog appears in the terminal, observe the sidebar indicator for that task — it should turn blue and pulse, staying blue until you make a choice.
  4. Approve or deny the permission. The indicator should immediately transition to amber (busy) if approved, or green (idle) if denied.
  5. Confirm the indicator does not revert to amber on its own while the dialog is still open.

🤖 Generated with Claude Code

simo787c and others added 2 commits May 8, 2026 14:28
Co-Authored-By: Claude <noreply@anthropic.com> via Dash <dash@syv.ai>
@simo787c simo787c requested a review from nthomsencph May 8, 2026 12:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants