Repository navigation
[Bug]: Completed OMP workers lose live status while Orca still shows in progress #26814
Description
Operating system
macOS
Orca version
v1.4.224
I check this behavior in the desktop UI on every new Orca release.
Details
Short summary
OMP (Oh My Pi) agents can still appear in progress after their turns and background jobs finish. In a two-worker run, both tasks succeeded, but one completed worker had no live status and was missing from orca worktree ps --json. The other worker correctly showed done.
This report adds the recorded macOS worker reproduction to the related reports below.
What happened?
The main agent and a worker were reported to remain in progress in the sidebar and tab after completing their work.
The diagnostic run below (tested on latest version):
| Worker | Task result | Dispatch | Live status |
|---|---|---|---|
| A | succeeded |
completed |
unavailable; liveness unverifiable; reason missing_status; activity unknown |
| B | succeeded |
completed |
fresh; activity done; main-agent outcome success |
Worker A completed a normal sleep 20 probe, then an asynchronous sleep 60 job. Its terminal showed the job completion notice, BACKGROUND_JOB_FINISHED, and the input prompt. Its OMP process was still open; this did not mean the task was still running.
orca worktree ps --json listed only worker B in agents, with state: done. Worker A was absent. The worktree showed status: working and workspaceStatus: in-progress.
The main agent was investigating when that command snapshot was taken, so its working state was expected then.
How can we reproduce it?
- Start two OMP workers through Orca.
- Let both tasks complete and leave their terminals open.
- In one worker, run a normal turn with
sleep 20, then a turn that starts an asynchronoussleep 60job. - Wait for the background job to finish and for the input prompt to return.
- Compare the terminal output, task and dispatch results, live status, sidebar, and tab indicator. Check
orca worktree ps --jsonfor the completed worker's row. - In a separate probe, try
/newand then complete another normal turn. The recorded probe restored a ready row after/new, but lost it again after the next completed turn.
Expected behavior
- Completed workers retain explicit
donestatus after all pending work finishes. - Sidebar and tab indicators agree with the execution host's status.
- Leaving an OMP process and terminal open does not keep the agent marked working.
- Normal turns, session reset, and background-job completion do not lose the status row.
- Actual active work still shows working; an input dialog still shows waiting.
Anything else that might help
The separate hook-delivery probe received HTTP 204 for before_agent_start, agent_start, message_end, and agent_end, but the stored status row was absent after completion. An HTTP acknowledgement alone did not prove that Orca kept the row. The cause of this recorded row loss was not established, and no status was changed by hand.
Related reports:
- [Bug]: OMP agent status remains stuck at "working" in sidebar after task completes (reproduces on v1.4.206) #22017: OMP remains working after a completed turn.
- [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: OMP loses its live status after a terminal repaint; that report identifies a command-finished marker as its trigger.
Related fix: #24196, fix: correct managed OMP status and readiness detection. The PR updates managed OMP lifecycle reporting and requires execution-host shell evidence before command-finished markers remove agent status. It also keeps completion information while background work finishes. The operator checks the desktop UI after every change and has confirmed that the fix works as expected.
Activity
AmethystLiang commentedon Oct 9, 2026
Thanks for reporting. Looking into it