[Bug] qqbot: AskUserQuestion option buttons are not routed — clicks produce no interaction, while permission buttons work

[Bug] qqbot: AskUserQuestion option buttons are not routed — clicks produce no interaction, while permission buttons work fine

Summary

On the qqbot platform, permission cards (allow / deny) work correctly — clicking a button produces a synthetic message and resolves the request.

AskUserQuestion cards do not. The option buttons render fine, but clicking them produces no interaction event at all. The only way to answer is to type a message — and whatever is typed (even a single character) is then silently accepted as the answer.

This makes multi-question AskUserQuestion effectively unusable on QQ: the card appears, clicking does nothing, and the user has to answer by typing, with no way to revise an earlier answer.

Environment

• cc-connect v1.5.0
• Platform: qqbot (QQ Bot, Official)
• Agent: claudecode
• OS: Windows 11
• intents: default 100663296 (bit25 + bit26, INTERACTION_CREATE included)
• markdown_support = true
• mode = "default"

Steps to reproduce

1. Ask the agent something that triggers a multi-question AskUserQuestion (e.g. any planning request).
2. The question card is delivered to QQ. It renders correctly, with option buttons.
3. Click an option button.
4. Nothing happens. The card does not update, no next question appears.

Typing an answer, however, does advance — which is why the symptom is often described as "I have to send a message before it moves on".

Evidence (cc-connect log)

One run. message received lines are classified by whether user is empty (synthetic → button click) or holds an openid (typed by the user):

01:35:07  message received  len=57   (typed)
01:35:16  claudeSession: permission request  tool=AskUserQuestion
01:35:17  permission request                 tool=AskUserQuestion
          <-- card delivered to QQ -->
01:35:49  message received  len=1    (typed)  <-- user clicks; nothing happens; so user types
01:36:23  message received  len=1    (typed)
01:36:38  message received  len=1    (typed)
01:36:53  message received  len=1    (typed)
01:36:54  permission resolved
01:37:00  turn complete

Zero synthetic message received lines (empty user) between 01:35:17 and 01:37:00.

Contrast with permission cards in the same session, where clicks clearly do work:

01:24:36  message received  len=4   user=""   <-- button click (synthetic)
01:27:06  message received  len=9   user=""   <-- button click (synthetic)

Also:

grep -ci interaction cc.out.log   ->  0

No interaction events are logged at all.

Root cause hypothesis

#1131 states:

Encode permission decisions and session key in button_data for routing callbacks Handle INTERACTION_CREATE events to process button clicks as permission responses

INTERACTION_CREATE clearly works — permission clicks arrive and resolve. But it looks like only permission decisions get encoded into button_data and routed. AskUserQuestion option buttons are not part of that routing, so their clicks are silently dropped.

Impact

• Multi-question AskUserQuestion is unusable on QQ.
• No way to go back and revise an earlier answer.
• Users work around it by typing, and that typed text silently becomes the answer — which can produce confusing results (e.g. a driver-typed Q, P, P, P being accepted as the four answers).

Related

• #1828 — instant card feedback via local card hooks; "Applies to both feishu and lark" → not qqbot
• #869 — multi-select in AskUserQuestion cards (open, feishu)
• #1778 — AskUserQuestion card 2.0 (open, feishu)
• #1184 — multiSelect rendered as single-click buttons (closed, feishu)

All AskUserQuestion work so far has been feishu-side. This report is specifically about qqbot.

Suggested direction

The mechanism proposed in #1828 — "sub-second, in-place card updates driven by a local script, no agent round-trip" — is exactly what's needed.

Multi-step navigation is a pure UI state machine. It should not require a model round-trip at all. If card_hook_dir could be extended to qqbot, both problems in this report (no routing, and the round-trip latency) would be solved at once — and it would also give users "back to previous question" and multi-select for free.