Summary

After a long troubleshooting session, the TUI kept showing the assistant as "streaming" long after the visible reply had already completed. Restarting the gateway sometimes cleared it temporarily, but the indicator returned, so restart appears to mask the symptom rather than fix the root cause.

Environment

• OpenClaw: 2026.4.5
• Model: openai-codex/gpt-5.4
• Surface: openclaw-tui / direct session

Context / trigger

This showed up during a long session that included:

• plugin install and config changes
• gateway restarts
• channel debugging
• WeChat (openclaw-weixin) setup and verification
• a previously linked ACP child session still appearing in parent metadata

The WeChat setup was eventually successful, so the stuck streaming symptom appears to be separate from final channel health.

Steps to reproduce

Not yet reduced to a minimal repro, but the symptom appeared after a long live session with:

1. multiple tool calls
2. several exec diagnostics
3. gateway restarts
4. plugin/channel setup
5. continued chatting in the same session

Observed behavior

• TUI still shows the assistant/session as streaming after the reply is visibly done
• This persists long after typing/output has stopped
• Restarting the gateway can temporarily clear it
• The symptom can return later
• At the time of investigation:
  • no meaningful active background exec remained
  • no active subagents remained
  • completed debug commands had already exited
  • an old linked ACP child session reference was still present in parent metadata

Expected behavior

Once the assistant reply is complete and there is no active task still producing output, the TUI should stop showing the session as streaming.

What was ruled out

• Not simply an active WeChat setup task
• Not explained solely by lingering debug exec commands
• Not explained by active subagents
• Not fixed permanently by gateway restart

Likely cause / hypothesis

A TUI or session-state bug, possibly caused by one of:

• stale running/streaming state in the parent session
• stale child-session metadata, especially an old linked ACP child
• queue/session lifecycle state not being cleared cleanly after complex tool-driven turns
• UI treating session state too literally after prior activity

Extra clue

A stale linked child ACP session remained visible in the parent session metadata:

• agent:codex:acp:a542397c-a6f3-419c-a4f2-f758f263632c

This did not appear to be an actively running worker, but it may still be relevant to how the TUI decides the session is "streaming".

Impact

• misleading UI state
• makes it look like the assistant is still busy or hung
• reduces trust in whether the system is actually idle