Surface pending Claude Code prompts on-device and answer them by touch

[Chemaclass]

Summary

Right now Clawdmeter is one-directional: the daemon polls usage and pushes it to the device. It would be great to close the loop so the device can also alert me when Claude Code is blocked waiting on input (a permission prompt or a multiple-choice question), let me see the prompt on the AMOLED ASAP, and tap one of the predetermined options on the touchscreen so Claude keeps working without me touching the keyboard.

Motivation

When you step away from the desk, a Claude Code session often stalls on a question/permission prompt. You don't notice until you look back at the terminal, so the agent sits idle. The device is already on my desk in my peripheral vision, which makes it the perfect place to get notified and unblock the session with a single tap.

Proposed behavior

1. Detect a pending prompt. Daemon detects when the active Claude Code session is waiting on user input (permission request or AskUserQuestion-style multiple choice).
2. Notify on-device. Device draws attention (animation/flash + optional sound/buzz) so I see it ASAP from across the room.
3. Display the prompt. Show the question text and the predetermined options on screen. If options exceed screen height, the list scrolls.
4. Answer by touch. Tap an option directly in the UI; selection is sent back over BLE HID and Claude resumes immediately. The two physical buttons can stay as a fallback (cycle + confirm).

Open questions

• How does the daemon learn a prompt is pending? Usage headers won't carry this. Likely needs a hook into Claude Code itself (e.g. a Notification/Stop hook, or reading the session transcript) rather than the API poll. Worth confirming what's exposed before building.
• Channel back to Claude Code. Mapping a tapped option to BLE HID keystrokes (arrow keys + enter) needs the device to know the prompt's option layout to drive the TUI selection correctly.

Out of scope (for now)

• Free-text answers. Device input is limited to selecting predetermined options.

[HermannBjorgvin]

Take a look at #22 you might find it relevant or interesting

I agree this would be a nice feature to have. The UX and such just need to be refined in such a way that it doesn't detract from the current UX and makes sense for the device form factor.

[Chemaclass]

Did a bit of scoping + a host-side spike. Two takeaways:

This builds on #22. That PR already has the hook (clawdmeter_hook.py), the state.json handoff, the daemon→BLE push, and the morphing splash slot. #94 is just one extra layer: make the hook wait for an answer from the device on a permission event instead of returning immediately.

The risky parts can be designed away. I tested this against Claude Code 2.1.195:

• A PreToolUse hook gets the full tool name + input and can return allow/deny — both honored.
• It can block while it waits (~25s+); Claude waits, then acts on the answer. So a "push to device → wait for tap → return decision" round-trip works.
• If no answer comes (device offline), Claude falls back to the normal terminal prompt and runs nothing without approval — a dead device can't cause an unwanted allow.

So: no HID keystroke injection, no TUI scraping. The hook itself is the answer channel.

Proposed v1 scope (smallest reliable cut):

• Permission prompts only.
• Answer = allow/deny, via the physical side buttons (fits your note that touch buttons complicate the UI). Touch optional.
• Reuse Activity screen: live Claude Code session state from hooks #22's morph slot — no new screen.
• Timeout → fall back to the normal prompt. Safe by default.

Out of scope for v1: AskUserQuestion multiple-choice (needs the hook to return a chosen option, not just allow/deny — separate spike first) and free-text.

Question: ride this on #22 (land it first, or prototype on activity-and-hooks)? Happy to help with #22's merge conflicts either way.