feat: real-time feedback signals during tool execution — thumbs up/down/halt without full interrupt

Problem

When Claude is executing a multi-step task (running tools, writing code, exploring the codebase), the user's only options are:

1. Wait silently until Claude finishes — then redirect if the approach was wrong
2. Type a message — which triggers a system-reminder interrupt that Claude may not see until the current tool completes, and which requires formulating a full thought in text

There's no middle ground. No way to say 'yes, keep going' or 'wrong direction' or 'pause, I have context' without stopping the world.

In a real team, you can nod, shake your head, raise a finger, or make a face while someone is presenting. You don't have to wait for them to finish and then say 'actually, go back to slide 3.' The feedback is continuous and lightweight.

Proposed: Real-time feedback signals

Three non-blocking signals the user can send while Claude is working:

| Signal | Meaning | Effect |
|---|---|---|
| 👍 (thumbs up) | 'Good direction, keep going' | Claude sees confirmation, continues with confidence |
| 👎 (thumbs down) | 'Wrong direction' | Claude pauses current approach, asks what to change |
| ✋ (halt) | 'Stop, I have something to say' | Claude stops current tool chain, waits for input |

How it could work

• Small floating UI (3 buttons) visible whenever Claude is actively executing
• Signals are delivered as lightweight metadata, not full messages — they don't require Claude to process a text prompt
• 👍 could reduce unnecessary 'does this look right?' questions — the user already said yes
• 👎 stops wasted tokens on a wrong approach — Claude would otherwise finish the full chain before learning it was wrong
• ✋ is a clean pause that doesn't require typing 'STOP' and canceling tool use

Why this matters

Token efficiency

Right now, if Claude is on step 3 of 5 and the user realizes step 2 was wrong, Claude finishes steps 3-5 before the user can redirect. Those tokens are wasted. A 👎 at step 3 saves steps 4-5.

Context quality

The current interrupt mechanism (typing a message during execution) creates system-reminder noise in the conversation. Multiple interrupts stack up. A thumbs up/down is metadata, not conversation — it doesn't pollute the context window.

Learning

Continuous feedback is richer than end-of-task feedback. Claude could learn 'this user gives 👍 when I explore before implementing' or '👎 when I make assumptions without asking.' The signal-to-noise ratio is much higher than waiting for a text correction after the fact.

Collaboration feel

The current model is turn-based: Claude works → user reviews → Claude works. Real collaboration is continuous. Signals make it feel like pair programming, not code review.

Example scenario

Claude is fixing a bug. It reads 3 files, identifies the issue, and starts writing a fix.

Today:

• Claude writes the fix (wrong approach)
• Claude runs tests (they fail)
• Claude tries another fix
• User finally types 'wait, the issue is in a different file'
• 3 wasted steps

With signals:

• Claude reads 3 files → user sees it heading to the wrong file → 👎
• Claude: 'Wrong direction — what should I look at?'
• User: 'check the middleware, not the route'
• 1 step, correct direction

Implementation notes

• Signals could be special keybindings in the CLI (e.g., Ctrl+Y = 👍, Ctrl+N = 👎, Ctrl+H = halt)
• In the desktop app / VS Code extension, floating buttons
• Signals are persisted as conversation metadata, not messages — they inform Claude's behavior without consuming context
• The 👍 signal could also serve as a 'pre-approval' for the current tool use, reducing permission prompts