Summary

The TUI queue/escape flow has multiple user-visible problems around queued submits and aborting the active run.

Observed behavior

• Submitting while a run is active enters a queued state, but the UX is confusing/inconsistent.
• Queued prompts should not appear in the transcript until they are actually sent.
• The footer can stay stuck on streaming with a stale tool: exec badge even after the run is visibly done.
• Pressing Esc to abort/flush can fail with:
  • abort failed: GatewayClientRequestError: TypeError: Cannot read properties of undefined (reading 'get')

Repro

1. Start a run in openclaw-tui that streams for a bit / invokes tools.
2. Submit another prompt while the first run is active.
3. Observe queue behavior and footer state.
4. Press Esc to abort the current run / advance the queued item.

Actual

• Queue submission/acknowledgment is easy to misread.
• Footer can remain streaming after completion.
• Esc abort path can throw the GatewayClientRequestError / undefined.get failure above.

Expected

• Queued items stay out of the transcript until actually dispatched.
• Queue submission is acknowledged clearly but truthfully.
• When a run finishes, the footer should return to a non-busy state and clear stale tool labels.
• Esc should reliably abort the active run and then flush/send the next queued item without throwing.

Notes

I checked for an existing matching issue and didn’t find one via gh search issues for combinations of:

• tui queued transcript
• tui streaming done
• queue escape tui
• tui escape abort failed GatewayClientRequestError

There are local fixes/work-in-progress around this area, but the abort failure still needs a proper root-cause fix.