Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Gateway never clearing streaming: true flag for main session [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63979•Fetched 2026-04-10 03:41:28
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
patrissimopatrissimo
Participants
neeravmakwananeeravmakwanapatrissimopatrissimo
Timeline (top)
labeled ×2commented ×1cross-referenced ×1

In my TUI, only for my main agent/main session starting this afternoon, after a reply it always says "Streaming" and the time ticks up. It was not able to debug this itself, and here is a summary of what it discovered. It believes there is a gateway session state handler bug. One context of note - at around the same time, I had an issue where my claw was trying to restart the gateway, which is managed by launchd, and there were 2 gateways trying to start for awhile.

The Bug:

  • After an agent.turn call completes and the agent replies, the main session stays marked as streaming: true
  • The timer keeps ticking up
  • This happens regardless of sub-agents, cron, or other activities
  • Only the main agent session exhibits this—Bates-CD works fine
  • Fresh sessions immediately show the same bug
  • The issue is not something I (the agent) can fix—it's a gateway state machine bug

Evidence:

  1. Gateway log shows "New session, no streaming?" at 18:32:37 (after agent.wait completes)
  2. sessions.list is being called repeatedly, always returning streaming: true
  3. The streaming flag is never cleared by the gateway
  4. TUI status shows ⠇ streaming • 39s+ with clock ticking

Root Cause (Hypothesis):

  • The gateway's session state handler has a bug where it doesn't clear the streaming flag after a run completes
  • Likely in agent-runner.runtime, session-updates, or the WebSocket handler that manages sessions.list responses
  • The flag may be stuck in the session metadata or the gateway's in-memory session state

Recommendation: This needs a bug report to the OpenClaw team with:

  • Main session only exhibits this, Bates-CD doesn't
  • Persists across fresh session creation
  • Related to sessions.list response metadata
  • Gateway restart doesn't fix it
  • Happens with zero sub-agents/cron running

Root Cause

Root Cause (Hypothesis):

  • The gateway's session state handler has a bug where it doesn't clear the streaming flag after a run completes
  • Likely in agent-runner.runtime, session-updates, or the WebSocket handler that manages sessions.list responses
  • The flag may be stuck in the session metadata or the gateway's in-memory session state

Fix Action

Fixed

PR fix notes

PR #63988: fix(tui): reset footer activity to idle on session switch

Description (problem / solution / changelog)

Summary

  • Problem: After streaming output, switching to another session could leave the TUI footer stuck on a busy state (for example streaming) because completion events for the previous session are no longer applied, so nothing cleared the activity label.
  • Why it matters: The status line and timer can suggest work is still in progress when it is not.
  • What changed: setSession now calls setActivityStatus("idle") when the selected session changes, after clearing activeChatRunId.
  • What did NOT change: Per-event chat finalization for a single session, gateway session listing, and unrelated TUI behavior.

Change Type

  • Bug fix

Scope

  • UI / DX

Linked Issue/PR

  • Closes #63979

Root cause

Session switch cleared the active run id but not the footer activity state. Chat events for the previous session are filtered by session key after the switch, so the handler never ran the path that sets activity back to idle.

Regression tests

  • Unit tests in src/tui/tui-session-actions.test.ts: assert setActivityStatus("idle") on session switch; dedicated case after a streaming-style busy state.

User-visible changes

TUI: switching sessions resets the footer activity line to idle so a stale busy label (for example streaming) does not persist.

Security Impact

  • New permissions/capabilities: No

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +2/-0)
  • src/tui/tui-session-actions.test.ts (modified, +68/-1)
  • src/tui/tui-session-actions.ts (modified, +3/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

In my TUI, only for my main agent/main session starting this afternoon, after a reply it always says "Streaming" and the time ticks up. It was not able to debug this itself, and here is a summary of what it discovered. It believes there is a gateway session state handler bug. One context of note - at around the same time, I had an issue where my claw was trying to restart the gateway, which is managed by launchd, and there were 2 gateways trying to start for awhile.

The Bug:

  • After an agent.turn call completes and the agent replies, the main session stays marked as streaming: true
  • The timer keeps ticking up
  • This happens regardless of sub-agents, cron, or other activities
  • Only the main agent session exhibits this—Bates-CD works fine
  • Fresh sessions immediately show the same bug
  • The issue is not something I (the agent) can fix—it's a gateway state machine bug

Evidence:

  1. Gateway log shows "New session, no streaming?" at 18:32:37 (after agent.wait completes)
  2. sessions.list is being called repeatedly, always returning streaming: true
  3. The streaming flag is never cleared by the gateway
  4. TUI status shows ⠇ streaming • 39s+ with clock ticking

Root Cause (Hypothesis):

  • The gateway's session state handler has a bug where it doesn't clear the streaming flag after a run completes
  • Likely in agent-runner.runtime, session-updates, or the WebSocket handler that manages sessions.list responses
  • The flag may be stuck in the session metadata or the gateway's in-memory session state

Recommendation: This needs a bug report to the OpenClaw team with:

  • Main session only exhibits this, Bates-CD doesn't
  • Persists across fresh session creation
  • Related to sessions.list response metadata
  • Gateway restart doesn't fix it
  • Happens with zero sub-agents/cron running

Steps to reproduce

NOT_ENOUGH_INFO

Expected behavior

After giving a reply in TUI, status reads "connected | idle".

Actual behavior

No amount of gateway restarts, session /reset, or even an attempt to delete the session from the session store, changed this behavior. I ended up abandoning the agent/session as my other sessions are fine.

OpenClaw version

2026.4.5 (3e72c03)

Operating system

macOS 15.6

Install method

No response

Model

anthropic/claude-haiku-4-5

Provider / routing chain

???

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: My main session and agent Severity: Annoying; but also is probably chewing up system resources as it hangs Frequency: Always (on the borked session).

Additional information

No response

extent analysis

TL;DR

The gateway's session state handler likely has a bug that prevents it from clearing the streaming flag after a run completes, causing the main session to remain in a "streaming" state.

Guidance

  • Verify the issue by checking the gateway logs for the "New session, no streaming?" message and observing the sessions.list responses to confirm the streaming flag is not being cleared.
  • Investigate the agent-runner.runtime, session-updates, or WebSocket handler code to identify the potential bug causing the issue.
  • Try to reproduce the issue with a minimal setup to isolate the problem and provide more detailed information for the OpenClaw team.
  • Consider providing more details about the environment, such as the provider/model setup and routing chain, to help the OpenClaw team better understand the issue.

Example

No code snippet can be provided without more information about the specific codebase and technologies used.

Notes

The issue seems to be specific to the main agent session and is not resolved by restarting the gateway or creating new sessions. The OpenClaw team may need more information to diagnose and fix the issue.

Recommendation

Apply workaround: While waiting for the OpenClaw team to address the issue, consider using a different session or agent to minimize the impact of the bug.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

After giving a reply in TUI, status reads "connected | idle".

#conversation history#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING