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

[jodybrownell]

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

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.