[Bug] Feedback mechanism accepts terminal input as feedback rating

Resolved 💬 3 comments Opened May 3, 2026 by srwlli Closed May 7, 2026

Bug Description
---
Bug: Feedback prompt captures next user input as rating without distinguishing it from regular conversation

Symptom: When the feedback prompt appears mid-session and the user's next input is intended as a reply to Claude (e.g., picking option "1" from a list Claude just presented), the feedback mechanism interprets that input as the rating value. The user submits a "1" star feedback unintentionally.

Repro:

  1. Claude presents numbered options (e.g., "Pick 1, 2, or 3").
  2. The feedback prompt appears in the same turn or immediately after.
  3. User types 1 intending to answer Claude.
  4. Feedback mechanism captures 1 as the rating; the actual conversational reply is consumed.

Impact: Distorts feedback telemetry. Users submit ratings they didn't mean to give, and Claude never receives the intended reply — silently dropped.

Reported: This is a recurring issue. Filed previously without resolution.

Proposed fixes (any one resolves it):

  1. Require an explicit prefix or modal interaction. Feedback rating only accepts input prefixed with a sentinel (e.g., /rate 1, feedback: 1) or via a separate UI affordance the user must explicitly invoke. Bare numeric input stays in the conversation stream.
  2. Disambiguate at submission time. When numeric input arrives during an active feedback prompt, surface a confirmation: "Submit 1 as feedback rating, or send to Claude?" — default action is "send to Claude" so silence preserves conversation, not feedback noise.
  3. Time-box the feedback prompt narrowly. The prompt only accepts input within N seconds of the prompt appearing. After that, input routes to the conversation. Removes the ambient capture window.
  4. Decouple input streams entirely. The feedback prompt is rendered in a separate input field or modal. The main conversation input continues to flow to Claude regardless of whether feedback is pending.

Severity: Medium. Doesn't break functionality but corrupts a critical trust signal (feedback is supposed to reflect user intent, not random conversational input)

Environment Info

  • Platform: win32
  • Terminal: windows-terminal
  • Version: 2.1.114
  • Feedback ID: 356546d2-00fc-4c3f-8144-78182728a06f

Errors

[{"error":"Error: 429 {\"type\":\"error\",\"error\":{\"type\":\"rate_limit_error\",\"message\":\"This request would exceed your account's rate limit. Please try again later.\"},\"request_id\":\"req_011CagCQZ9cV3rTyLs9HaqoJ\"}\n    at generate (B:/~BUN/root/src/entrypoints/cli.js:11:53135)\n    at makeRequest (B:/~BUN/root/src/entrypoints/cli.js:50:4943)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-03T19:35:51.577Z"},{"error":"Error: Request was aborted.\n    at makeRequest (B:/~BUN/root/src/entrypoints/cli.js:50:3448)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-03T22:14:21.924Z"}]

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗