Dashboard worker terminal floods with Device-Attributes reports (ESC[>84;0;0c) under mux WebSocket reconnect loop (0.9.2, tmux+cursor-agent)

[chetwerikoff]

Summary

On AO 0.9.2 (tmux runtime, Cursor cursor-agent workers), the dashboard worker terminal floods with terminal Device-Attributes reports — thousands of ESC[>84;0;0c (Secondary DA / DA2) plus occasional ESC[?1;2c (Primary DA) — written into the persistent pane. The flood is tightly correlated with the dashboard terminal mux WebSocket reconnecting ~once per second. Consequences:

• The worker TUI (cursor-agent) is pegged re-rendering (~20%+ CPU) for a session that is otherwise idle.
• Messages injected via ao send / ao review send land in the agent input as an unsubmitted paste ([Pasted text #N +K lines]) and are never consumed — so review findings silently never reach the worker.
• The native activity probe reads the flooded pane as idle/garbage and can mark the session stuck (probe_failure), risking respawn/kill of a worker that actually finished and is awaiting review.

Environment

• AO 0.9.2, Linux/WSL2, tmux runtime.
• Worker agent: Cursor cursor-agent (Composer 2.5) launched under a tmux session.
• Dashboard next-server on :3000.

Observed (two incidents, same day)

Two separate worker sessions, same failure signature:

1. opk-8 / PR fix: preflight agent binary on spawn #166 — review run produced a finding, AO marked it sent_to_agent, worker never transitioned to addressing_reviews; pane flooded with ESC[>84;0;0c; session went stuck (probe_failure, evidence idle_beyond_threshold).
2. opk-10 / PR feat(codex): auto-update session metadata for Codex agents #169 (recurrence) — finding from review run c134e976 injected into the pane (visible as [from orchestrator] Pending AO review finding … Please fix, then ao report addressing_reviews) but shown as [Pasted text #5 +22 lines] and not submitted; ~480 ESC[>84;0;0c reports in one pane capture; session idle, finding lost.

In both, ao events list shows ui.terminal_connected / ui.terminal_disconnected (mux WebSocket) alternating roughly every second (e.g. 35–46 of the last 50 events are this connect/disconnect pair).

Likely mechanism (observable, not internal-confirmed)

Each mux (re)attach appears to (re)initialize the terminal and emit terminal-capability / DA queries; the pane terminal answers with DA reports, and under sub-second reconnect flapping the answers accumulate in the pane scrollback faster than they drain — a self-reinforcing loop once the pane is large/busy.

Request

1. Do not let terminal-capability / DA query responses accumulate in the persistent worker pane — sanitize/reset terminal state on mux (re)attach instead of replaying/echoing capability probes into the pane.
2. Throttle / back off the mux WebSocket reconnect loop so a struggling terminal stream cannot flap at ~1 Hz and feed the loop.
3. Ensure the native activity probe does not classify a DA-flooded pane as idle→stuck, and that injected input (ao send) is delivered as a submitted line rather than an unsubmitted paste when the pane is busy.

Impact

Silent loss of review findings to workers and false-stuck classification of healthy, review-ready workers — the review→fix loop stalls with green CI and "0 open findings" while the fix never lands.

Happy to provide full ao events, session JSON, and pane captures.