[Bug]: Claude AskUserQuestion with a blank option description fails the run and wedges the thread #15316

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the clear writeup and root cause, @tarik02! I can confirm this on current main (39efcd8558). A blank option description is enough to fail the run and leave the Claude session stuck.

   What fails

   claudeUserInputQuestions in apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts keeps any non-empty label and sets description to the trimmed string, or to "" when the field is missing or isn't a string. OrchestrationV2UserInputQuestion in packages/contracts/src/orchestrationV2.ts types that field as TrimmedNonEmptyString, so both "" and whitespace-only text fail Schema.isNonEmpty().

   ProviderEventIngestor.makeDomainEvent decodes the turn_item.updated event before writing it, and that decode error fails the run's event consumer. RunExecutionService's catchCause logs orchestration V2 provider event ingestion failed and writes a failed terminal through makeProviderFailure. causeMessage doesn't recognize schema errors, so the thread just shows the generic "Provider turn failed."

   That write doesn't interrupt the provider session. canUseTool is still waiting inside awaitClaudeUserInputAnswers, and activeTurn stays set. The next message hits startTurn's guard and fails with ProviderAdapterProtocolError: Claude provider turn … is still active until the query process exits and finalizeActiveTurnAfterQueryExit clears it, which is why killing that process works around it.

   The question card never appears because the questions only live on the user_input_request turn item, and that's the event that fails to decode. The node and runtime request emitted just before it can still land, so a pending request can show up with nothing to answer. "Waiting on background task AskUserQuestion" is the composer strip for the still-open Claude task (presentPendingBackgroundWork).

   Other adapters

   Codex (nonEmptyText(option.description, option.label)) and both OpenCode adapters already fall back to the label. Pi's extension select dialog doesn't: piQuestion uses label: option || "Empty value" but description: option, so an empty-string option still fails. Grok's extractXAiAskUserQuestions uses option.description ?? option.label, which covers a missing description but still passes an explicit "" through.

   Likely fix area

   • One option is to fall back to the option label wherever a question option is built, at least in claudeUserInputQuestions and Pi's select mapping (and possibly the Grok path for explicit ""). That matches the adapters that already decode cleanly, and it lets the card show and the run wait.
   • Separately, interrupting the provider when ingestion fails would unstick the thread, though on its own it would still drop the question.

   The open PR #15317 proposes the label fallback for Claude and Pi, with decode tests. A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026
3. darjss commented on Oct 7, 2026

   

   darjss

   on Oct 7, 2026

   Contributor

   More actions

   The same wedge happens with ACP providers (AcpAdapterV2), so a fix in RunExecutionService (#14856) would cover more than Claude.

   What I checked on main (bfec2387b8). I started an ACP turn whose prompt never returns, then called startTurn twice more on the same runtime. Both calls failed with ProviderAdapterTurnStartError, which wraps ACP provider turn … is still active (AcpAdapterV2.ts:6826). The only place activeTurn is cleared is finalizeTurn (AcpAdapterV2.ts:6660), and that never runs once the orchestrator has failed the run without interrupting the provider turn. The thread stays stuck until the orphaned prompt ends or the server restarts.

   A likely ACP trigger, not reproduced end to end. Form elicitations map each enum value to { label: value, description: value } (AcpAdapterV2.ts:5844). An empty or whitespace-only enum value would produce the same blank label/description that fails OrchestrationV2UserInputQuestion here. The agent would then stay blocked on elicitation/create while the run is marked failed. I have only read this path in the code and haven't seen it from a real agent. Filtering blank enum values, or falling back to a default label as the Codex and OpenCode adapters do, would close it.

   Model/harness: Claude Opus 5.5 via Claude Code.
4. Ieruss commented on Oct 8, 2026

   

   Ieruss

   on Oct 8, 2026

   More actions

   Another trigger for the same bug: a Claude Code plugin dialog. It reproduces on 0.0.46-nightly.20261008.2813 (macOS desktop, Claude provider, orchestration V2).

   The prompt-coach plugin calls $.ui.ask(...) in its prompt.submit hook with three options. None of them has a description. The SDK delivers this as an AskUserQuestion canUseTool request with every option's description: "":

   {"questions":[{"question":"Prompt coach: …\n\nWhich should I send?","header":"Coach","options":[{"label":"Send improved","description":""},{"label":"Send mine","description":""},{"label":"Edit improved","description":""}],"multiSelect":false}]}

   Same outcome as described above:

   • No question card. The timeline only shows the AskUserQuestion tool row with the raw JSON input. In the projection this is a dynamic_tool turn item, and no user_input_request item was written.
   • The user_input runtime request and the user_input_request node stay pending/waiting. t3_pending_request_list still lists all three requests from this thread, although their runs are interrupted.
   • The turn ends with "Provider turn failed."

   Because the plugin runs on every prompt it judges vague, this hits plain user messages, not only agent questions. In my thread it fired 3 times. One of those stopped turns also led to #17133.

   The label fallback in #15317 should cover this case too, since the label is always non-empty here.