[Bug]: OMP agent status vanishes mid-turn after any repaint of a user message (OSC 133;D retires launch authority; later hooks silently 204'd) #24436

Operating system

Windows 11 10.0.26200 with WSL2 Ubuntu 24.04 (kernel 6.18.33.2, mirrored networking)

Orca version

1.4.218 (OMP 18.4.9)

Details

Summary

While an OMP turn is still running, its row disappears from the sidebar and from orca worktree ps --json (agents[]), and the pane reads as idle for the rest of the turn. OMP keeps posting status hooks, and the hook server answers every one with HTTP 204, but none of them are applied. The pane recovers only when the next prompt sends before_agent_start.

Trigger: OMP wraps every rendered user message in OSC 133 marks ending with OSC 133;D;0 (can1357/oh-my-pi#8213). Orca treats that 133;D as the launched command finishing and retires the pane's agent-status authority even though the agent is still running.

Reproduction (deterministic, no synthetic input)

1. Open an OMP terminal through Orca, e.g. orca terminal create --worktree active --command omp.
2. Prompt: Use your bash tool to run exactly `sleep 60` (no other commands), then reply with the single word done.
3. While sleep 60 runs, confirm the agent shows working/bash (sidebar or orca worktree ps --json).
4. Split that pane (orca terminal split --terminal <handle> --direction horizontal, or Split Right in the UI). OMP gets SIGWINCH and repaints its transcript, re-emitting the user message's 133;A/B/C/D;0.
5. Within a second the agent row is gone. It stays gone for the rest of the turn, and the turn's completion is never shown.

Without any resize, 4 of 24 real-prompt trials also lost status right after submit. OMP paints the user message (two 133;A/B/C/D;0 sets within ~70 ms, confirmed with script(1)) at the same moment it posts before_agent_start, so the PTY bytes sometimes land after the hook. In daily use this shows up as long OMP turns sitting grey/idle after a resize, split, or window or sidebar change.

Root cause (1.4.218 bundle)

1. The PTY fact scanner emits command-finished for every OSC 133;D in pane output.
2. emitDaemonPtyTransientFact / title-tracker onCommandFinished → retirePtyAgentLaunchAuthority(ptyId) → retireAgentHookCompatibilityAuthority(paneKey) → retirePaneAuthority → markPaneClosedForAgentStatus, and the status row is deleted.
3. getAgentStatusDisposition returns suppress for every event on a closed pane except a new-turn event. For omp that is only before_agent_start (Vn), so tool_execution_start, tool_execution_end, message_end and agent_end are all dropped while the hook server still replies 204.

Expected

An OSC 133;D written by a still-running agent TUI should not be treated as the launched agent exiting. Possible fixes:

• Only honor command-finished for launch authority once the shell is back in the foreground or agent exit is confirmed.
• Or ignore OSC 133 marks while the launched agent is the PTY foreground process.
• Or let a pane whose authority was retired accept non-new-turn events again when the event's launch token still matches the live launch.

Related

• [Bug]: Re-attached Pi pane permanently suppresses working/done status in main and renderer retired-pane tombstones #14236: the same closed-pane suppression gate (204 + only new-turn events reopen), with a different trigger (reattach + Pi event names). The fix there added before_agent_start to the new-turn list but kept the gate.
• [Bug]: OMP 17.2.12+ loses working status and can leave a spinner stuck on WSL #13890: OMP loses working status on WSL; different cause (title classification).
• [Bug]: Windows PowerShell startup agents remain listed after their process exits #18180: Orca's use of 133;D as the ended-process signal (the PowerShell side).
• While writing the harness, terminal wait --for tui-idle never matched OMP 18.4's idle title ([Bug]: worker-start --agent omp fails at agent_readiness: OMP 18.4 idle title "π > dir" is not recognised as idle #24068).