[Bug]: questions do not open and garble leading to deadlock "Waiting for earlier responses"

[WolfgangFahl]

App Variant

Electron

Operating System & Version

macOS 14.6.1

Issue Summary

Questions are not shown automatically anymore. They pile up garble and the interaction ends in a deadlock.

Steps to Reproduce

1. add prompts that lead to subagents creating questions (i assume two parallel subagents are causing the issue)
2. see main prompt blocking without showing questions
3. try to answer questions and get "waiting for prior question"
   Unclear what the prior question is or cyclic wait - i do not know i am or feel in a dead lock have to destroy the instance / session and start all over again.

This happened around a dozen times in the past few days.

Expected Behavior

no deadlock questions either show automatically or when selected

Logs & Screenshots

showing for both questions - none can be answered

Additional Context

No response

[shantur]

Hey @WolfgangFahl,

Thanks for raising this.
Can I trouble you to give me a prompt that probably leads to this situation?
I see that you mention parallel subagents and also main agent too so I am not 100% sure how to reproduce this

[WolfgangFahl]

I did

git clone https://github.com/WolfgangFahl/PyExpireBackups

browsed the pyExpireBackups directory selected Model DeepSeek V4 Pro via Openrouter
and prompted:

• how can i force you to ask interactive questions?
• no i want to answer [Bug]: questions do not open and garble leading to deadlock "Waiting for earlier responses" #448 (comment)

I end up with

This time i can not select a second question but the deadlock effect is the same. The question also did not auto open.

[WolfgangFahl]

Here is another example where i get two identical questions and it seems they wait for each other

[shantur]

Thanks @WolfgangFahl

Can I see your permissions configuration for your project and global?
I wonder if it is something to do with permissions + questions happening at the same time.

I spent sometime right now and I can't get into the state however many questions I could try to generate

[WolfgangFahl]

Can I see your permissions configuration for your project and global?

If i would know what you are talking about yes. In mac os i get lots of permission requests on OS level and often as question. CodeNomad itself does not have any settings or permissions menu. Things are hidden in a self created UI that i have no clue about and keep misunderstanding.

the two concepts

• project
• global

are quite abstract and have diverse meaning
project

• github project
• the project i am working on
• in CodeNomad itself there are folders and instance but not projects

global

• global variable
• server global - e.g environement settings
• user global

[shantur]

I mean permissions configuration in opencode.json or opencode.jsonc
It is in .opencode folder in project and in ~/.config/opencode folder

https://opencode.ai/docs/config/#locations

https://opencode.ai/docs/permissions

[shantur]

@CodeNomadBot

Analyse the questions and permissions flow in packages/ui
Check this issue and
Then try to investigate why could this be happening

[codenomadbot]

Investigation summary for packages/ui question/permission flow.

Request understood: analyze the UI-side questions + permissions flow and identify why issue #448 can happen. Assumption: this was an investigation request only, not a request to ship a code change yet.

What I found:

1. Pending permissions and questions are held in global per-instance queues in packages/ui/src/stores/instances.ts.

2. The UI computes one cross-kind active item via computeActiveInterruption() in packages/ui/src/stores/instances.ts:683-696. This means only the oldest permission/question is supposed to be answerable; later questions render as queued and show Waiting for earlier responses. from packages/ui/src/lib/i18n/messages/en/toolCall.ts:113.

3. Tool-call rendering does not render directly from that global queue. It first links each pending question/permission back to a message/tool part via the message-v2 store. For questions that happens in upsertQuestionV2() / reconcilePendingQuestionsV2() in packages/ui/src/stores/message-v2/bridge.ts:227-269, then lookup happens through getQuestionState() in packages/ui/src/stores/message-v2/instance-store.ts:1031-1037.

4. The likely deadlock is in packages/ui/src/stores/message-v2/instance-store.ts:986-1004. upsertQuestion() stores questions in questions.byMessage[messageKey][partKey], where partKey is the resolved tool part id when available. If two pending question requests resolve to the same messageId + partId (which matches the screenshots showing duplicate/identical questions), the later request overwrites the earlier request in byMessage while both requests remain in questions.queue and in the global instance question queue.

Why that matches the symptom:

• The global active interruption can still be the first/oldest question request.
• The rendered tool-call slot now points at the later duplicate request because the by-message entry was overwritten.
• ToolCall checks active state against activeInterruption() in packages/ui/src/components/tool-call.tsx:654-659.
• Since the rendered question id is not the active question id, the question block is disabled and shows Waiting for earlier responses. from packages/ui/src/components/tool-call/question-block.tsx:343-345.
• The truly active earlier question is no longer reachable through that tool-call lookup, so the UI can show one or more queued questions with no answerable active one. That looks like the deadlock reported here.

Secondary observation:

• The permission/question center is not auto-opened when requests arrive. InstanceShell2 only renders the banner and opens the modal on click (packages/ui/src/components/instance/instance-shell2.tsx:505-512, modal state at :122 / :1264-1268). Active inline tool calls are expanded/scrolled if already rendered, but child/subagent sessions or not-yet-loaded messages can leave the user with only the small banner. So the “question did not auto open” part is expected with current UI behavior, not necessarily a separate failure.

Likely fix direction:

• Do not key question lookup solely by messageId + partId when multiple pending question requests can share the same tool part.
• Preserve request-id identity in the message store lookup, or allow a tool part to expose all pending question entries for that part and choose/render the globally active one first.
• Add a regression test covering two pending QuestionRequests with different ids but the same messageId + callID/partId; the first request should remain renderable and active, and after it is removed the second should become active.

I did not make a code change in this pass because the comment asked for analysis/investigation. Confidence is high that the overwrite of same-part pending questions is the cause of the “both waiting for earlier responses” deadlock shown in the issue.

--
Yours,
CodeNomadBot

[shantur]

@CodeNomadBot

Different Questions can never have same messageId + partId.

1. Can it happen if same question is received twice somehow - maybe once in SSE other in loading instance
2. Can it happen if the permission is requested for a part that isn't present yet
3. What if a permission is requested for question

[codenomadbot]

Re-checking with that constraint: agreed, if different questions truly cannot share messageId + partId, then my previous “different request overwrote same tool-part slot” hypothesis should be downgraded. The code path I pointed at can overwrite by-message slots, but that is not a valid explanation if the backend invariant guarantees unique parts per question.

Answers to the three cases:

1. Same question received twice through SSE + hydration/list

• Unlikely to cause this deadlock by itself.
• syncPendingQuestions() calls addQuestionToQueue() and then upsertQuestionV2() (packages/ui/src/stores/instances.ts:250-255).
• addQuestionToQueue() deduplicates by request.id (packages/ui/src/stores/instances.ts:939-941), so the instance-level queue and activeInterruption() should not get two entries for the same question id.
• upsertQuestion() also replaces the message-v2 queue entry by request.id (packages/ui/src/stores/message-v2/instance-store.ts:995-1000).
• There is a minor stale-index risk if the same question is first stored before partId is known and later stored after partId is known: upsertQuestion() does not remove old byMessage mappings for the same request id, unlike permissions. But because inline lookup uses the actual tool partId, and the active id is unchanged, I do not think this explains “both waiting for earlier responses”. It is worth cleaning up, but it is probably not the root cause.

2. Permission requested before the part is present

• Yes, this can happen; the code explicitly supports it.
• upsertPermissionV2() queues the permission even if resolvePartIdFromCallId() cannot find a part yet (packages/ui/src/stores/message-v2/bridge.ts:169-183). In that case it is keyed by permission id in the message store, not by the eventual tool part.
• When a message.part.updated event later arrives for a tool part, handleMessageUpdate() calls reconcilePendingPermissionsV2() and reconcilePendingQuestionsV2() (packages/ui/src/stores/session-events.ts:376-380). reconcilePendingPermissionsV2() then tries to move the permission onto the resolved part (packages/ui/src/stores/message-v2/bridge.ts:186-216).
• While the permission is pending but not linked to an inline tool part, it can still be the global active interruption because computeActiveInterruption() uses the instance permission/question queues, not inline renderability (packages/ui/src/stores/instances.ts:683-696).
• That means a later question can render as queued/disabled with Waiting for earlier responses, while the actual earlier active permission is not visible inline yet. The permission center can still show and answer it, because its fallback renders permission actions even when the tool call cannot be resolved (packages/ui/src/components/permission-approval-modal.tsx:365-404).
• This is now my stronger explanation for the issue symptoms, especially combined with the modal not auto-opening. The user sees a visible question blocked by an earlier request, but the earlier request may only be available behind the small permission center button.

3. Permission requested for a question

• If a permission and a question are both associated with the same logical operation/tool area, the global ordering decides which one is active first (computeActiveInterruption()).
• If the permission is older, the question correctly becomes queued and disabled until the permission is answered. If that permission is not linked/rendered inline yet, it creates the same “question waits for invisible earlier response” scenario.
• If the question is older, the question can be active while the permission is queued. One inconsistency I noticed: QuestionToolBlock disables queued question inputs, but PermissionToolBlock still renders clickable buttons even when active=false (packages/ui/src/components/tool-call/permission-block.tsx:76-105). The permission center similarly allows permission actions regardless of active item. So permissions are not fully enforcing the same ordering discipline as questions.

Updated likely root cause:

• Not duplicate different questions on the same part.
• More likely: an earlier permission, possibly arriving before its tool part/message is renderable, becomes the active interruption and blocks a later visible question. Because the permission center does not auto-open, the user can perceive the visible question as deadlocked with “Waiting for earlier responses”.

Suggested next fixes/tests:

• Add a regression test for: permission arrives first with messageID/callID but no resolvable part; then question arrives and is visible. Assert the question is queued because the permission is active, and assert the UI has an obvious/actionable path to answer the active permission.
• Consider auto-opening or strongly surfacing the permission/question center when the active interruption is not currently renderable inline.
• Consider making queued permission actions disabled like queued question actions, or intentionally documenting/renaming the behavior if permissions are allowed out of order.
• Clean up upsertQuestion() stale byMessage mappings for duplicate same-id updates, mirroring the permission cleanup. Lower priority for this specific deadlock, but it removes a confusing edge case.

--
Yours,
CodeNomadBot