Summary

When the main agent delegates to one or more subagents, the subagents can complete successfully and the main agent can post the follow-up summary, but the WebChat UI may still leave the parent agent in a typing / processing state until the page is refreshed.

This appears to be a frontend state reconciliation bug rather than a backend orchestration failure.

Environment

• OpenClaw version: 2026.3.28 (f9b1079)
• Surface: Control UI / WebChat
• Browser: Safari
• Main model tested: GPT-5.4, DeepSeek
• Subagents involved in testing: Gordon, Lucius, Robin

Expected behavior

After subagents complete and the parent agent posts the final response, the typing / processing indicator should clear automatically.

Actual behavior

The parent agent's final response appears, but the UI can still show:

• typing bubbles
• red processing outline / active state

Refreshing the page clears the stuck state immediately.

Important observation

This does not appear to be a backend hang.

In my testing:

• subagents completed successfully
• the parent agent received the results
• the parent agent posted the final response
• refreshing Safari cleared the stale typing state immediately

That strongly suggests a WebChat frontend state bug.

Reproduction

1. Use the Control UI / WebChat in Safari.
2. Have the main agent delegate a task to one or more subagents.
3. Wait for the subagents to complete and for the main agent to post the final summary.
4. Observe that the main agent can remain visually in a typing / processing state.
5. Refresh the page.
6. Observe that the stale typing state disappears.

Notes

This reproduced with different main models, including:

• GPT-5.4
• DeepSeek

So it does not appear to be specific to one main model/provider path.

Suspected root cause

There appears to be a bug in the Control UI chat event handling for the case where a final chat event arrives with a runId different from the current pending chatRunId.

The UI accepts and appends the final assistant message in that branch, but does not clear the active pending run state.

That leaves the reply visible while the UI still believes a run is active.

Likely affected area

Source-mapped location appears to be:

• ui/src/ui/controllers/chat.ts

Specifically the branch equivalent to:

if (payload.runId && state.chatRunId && payload.runId !== state.chatRunId) {
 if (payload.state === "final") {
 const finalMessage = normalizeFinalAssistantMessage(payload.message);
 if (finalMessage && !isAssistantSilentReply(finalMessage)) {
 state.chatMessages = [...state.chatMessages, finalMessage];
 return null;
 }
 return "final";
 }
 return null;
}

The suspected problem is that this branch appends the final message but does not clear:

• chatRunId
• chatStream
• chatStreamStartedAt

Minimal fix idea

Clear the pending chat run state when accepting that cross-run final event:

if (payload.runId && state.chatRunId && payload.runId !== state.chatRunId) {
 if (payload.state === "final") {
 const finalMessage = normalizeFinalAssistantMessage(payload.message);
 if (finalMessage && !isAssistantSilentReply(finalMessage)) {
 state.chatMessages = [...state.chatMessages, finalMessage];
 }
 state.chatStream = null;
 state.chatRunId = null;
 state.chatStreamStartedAt = null;
 return "final";
 }
 return null;
}

Validation

A local patch implementing the above behavior resolved the issue in testing. After patching, a 3-subagent test run completed normally and the parent agent no longer remained stuck in typing state.

Impact

This can make successful multi-agent runs look hung or unfinished even though the backend has already completed correctly.