Skip to content

[Bug]: OMP 18's OSC 133 markers make Orca retire the pane mid-turn, dropping OMP status (stale/missing ask cards) #26933

Open
Open
[Bug]: OMP 18's OSC 133 markers make Orca retire the pane mid-turn, dropping OMP status (stale/missing ask cards)#26933
Assignees
Jinwoo-H
Labels
os:macosIssues affecting macOS

Description

@jairuspace
jairuspace
opened on Oct 9, 2026

Operating system

macOS

Orca version

v1.4.222 (also reproduced on main)

Details

Short summary:
With OMP (Oh My Pi) 18.x running in an Orca terminal, Orca stops accepting OMP's status updates shortly after each turn starts. The pane's agent status freezes, often on a stale "blocked" question, and every later status event is dropped until the next turn. The visible results:

  • in chat view, a second ask in the same turn never shows a question card, and the chat just says the agent is working;
  • the sidebar and other status readers show stale state for the rest of the turn.

Cause:

  1. Starting with OMP 18.0.0, OMP writes OSC 133 semantic-prompt markers around every user message it renders, for its own transcript outline. It writes \x1b]133;C\x07 immediately followed by \x1b]133;D;0\x07 (OMP packages/tui/src/chat/user-message.ts). OMP 17.x does not.
  2. Orca's terminal scanner treats 133;D as "the shell's foreground command finished". Both scan paths then retire the PTY's agent launch unconditionally:
    • visible: onCommandFinished → retirePtyAgentLaunchAuthority (src/main/runtime/orca-runtime-get-unpersisted-tracked-title-for-pty.ts)
    • background daemon: emitDaemonPtyTransientFact (command-finished) → retirePtyAgentLaunchAuthority (src/main/runtime/orca-runtime-emit-daemon-pty-transient-fact.ts)
  3. retirePtyAgentLaunchAuthority clears the PTY's launch token and launch agent, and calls retireAgentHookCompatibilityAuthority → AgentHookServer.retirePaneAuthority(paneKey).
  4. On a retired pane, getAgentStatusDisposition returns suppress for every event except a new-turn event. For OMP the new-turn event is before_agent_start, which revives the pane. OMP then renders the user message again, emits 133;D again, and the pane is retired again.

Evidence (dev build with temporary logging around hook ingest and retirePaneAuthority, fresh OMP 18.8.6 session):

ingest before_agent_start  → accept (applied)
ingest agent_start         → accept (applied)
retirePaneAuthority(<pane>) ← retireAgentHookCompatibilityAuthority ← retirePtyAgentLaunchAuthority ← emitDaemonPtyTransientFact
ingest tool_call  (ask)    → suppress   (pane closed)
ingest tool_execution_start (ask) → suppress

After an app restart, which clears the hook server's in-memory fences, the same OMP process's later events (tool_execution_end, message_end, agent_end) are accepted and applied, until the next turn's 133;D retires the pane again.

How can we reproduce it?

  1. Use OMP ≥ 18.0 (tested with 18.8.6).
  2. In an Orca terminal, start omp and send: "Use the ask tool with one question 'First?' (options A, B, C). After I answer, run echo hi, then use the ask tool again with one question 'Second?' (options X, Y)."
  3. Watch the pane's agent status, or switch the tab to chat view (⌘⇧J). The status never shows the first question as blocked, or it stays stuck on the first question. In chat view, the second question never gets a card even though OMP's dialog is waiting for it.

Anything else that might help:

Activity

  1. github-actions
    added
    os:macosIssues affecting macOS
    on Oct 9, 2026

  2. AmethystLiang commented on Oct 12, 2026

    @AmethystLiang
    AmethystLiang
    on Oct 12, 2026
    Contributor

    Thanks for reporting. Looking into it

  3. AmethystLiang
    assigned
    Jinwoo-H
    on Oct 12, 2026

  4. euclodius commented on Oct 14, 2026

    @euclodius
    euclodius
    on Oct 14, 2026

    Additional affected topology: Windows Orca 1.4.224 -> paired Linux headless Orca Server 1.4.224, with a fresh OMP 18.10.4 on WSL2. Direct loopback WebSocket access reproduced the accepted-hook-state loss, without an SSH tunnel.

    During an isolated sleep 45 turn, splitting the pane removed the accepted working hook entry before the tool finished. The managed reporter continued sending tool_execution_end, message_end, and agent_end; the observer recorded HTTP 204, while the host hook cache remained empty. The installed runtime still has both unconditional command-finished retirement paths described in this issue.

    The sidebar could retain a row through terminal-output-derived status, so I am confirming host hook-state loss, not claiming deterministic disappearance or an ask-card reproduction. On a separately paired Linux VPS I also observed an active OMP session displayed as stale Done, but did not capture its retirement trigger.

    This adds Windows-client/Linux-headless coverage to the existing macOS report. It does not establish that any candidate PR fixes this topology; no PR build was installed. Please keep #24436, #24732, and #24196 linked when validating the command-finished/authority transition.

    Detailed isolated reproduction: comment on #24436.

    AI assistance disclosure: prepared with an OpenAI coding assistant via OMP, using my reported behavior and local runtime diagnostics/source inspection. Reproduction and validation limits are stated above.

  5. sfc-gh-jimwu commented on Oct 15, 2026

    @sfc-gh-jimwu
    sfc-gh-jimwu
    on Oct 15, 2026

    Another reproduction on macOS, Orca 1.4.224 (8ba3cf4), OMP 18.11.1, with a different visible symptom: the UI stays stuck on working until the window is reloaded.

    Steps: orca terminal create --worktree active --command "omp --cwd /tmp/x", then prompt Reply with just the word pong. Do not use any tools.

    Polling orca worktree ps --json every 0.2-0.5 s, 3 of 3 runs:

    • about 1 s after submit: the pane's row is working
    • about 4 s later, mid-turn: the row is deleted and agentIdentity becomes null
    • the turn finishes: still no row
    • second prompt in the same pane: the row never comes back for the whole turn

    The tab spinner and the worktree's sidebar indicator stay on working after OMP is back at its prompt. A window reload (Cmd+R) clears them.

    Why the renderer stays stale: retirePaneAuthority (src/main/agent-hooks/server/server-authority-fences.ts:12-74) deletes the row and notifies only main-side listeners. It never calls emitPaneStatusCleared, which the other cleanup paths do (server-tab-cleanup.ts, server-cleanup.ts, server-tmux-status.ts). The renderer keeps its last working row. That row is fresh, so it takes precedence over the idle title (worktree-status.ts:100-103) until AGENT_STATUS_STALE_AFTER_MS (30 min) runs out. On reload, agentStatus:getSnapshot has no row, so the title fallback shows idle.

    So besides gating retirement on a confirmed shell foreground, retirePaneAuthority should probably send a renderer clear, so any retirement doesn't leave a ghost working state.

  6. teezeit commented on Oct 18, 2026

    @teezeit
    teezeit
    on Oct 18, 2026

    Still reproduces on macOS, Orca 1.4.229, OMP 18.12.1, with two more visible symptoms.

    1. Esc mid-tool leaves the tab spinner on "working"

    1. orca terminal create --worktree active --command "omp --extension ~/.omp/agent/extensions/orca-agent-status.ts --extension /tmp/evlog.ts" (evlog.ts is a small extension that appends every pi.on event to a file)
    2. Prompt: Run the bash command 'sleep 30' in the foreground, then reply done.
    3. Press Esc while sleep is running.

    OMP's events, in order: tool_execution_end, message_end (toolResult), message_end (assistant), agent_end, all within 2 ms. OMP is back at its prompt and its OSC title is idle, yet the tab keeps spinning. A new turn cleared it in this run. In another pane, though, the spinner stayed on "working" through two later turns that completed normally, which matches the "row never comes back" behaviour described above.

    2. The ask question icon sticks after the question is answered

    OMP called ask, so the tab showed the question icon. I answered, the agent kept running tools and finished the turn, and the question icon stayed through all of it, including after agent_end. This matches the "stale blocked question" in the original report.

    Ruled out on this setup: long-lived background processes started by the agent (running or exiting), and OMP's /btw side questions, which emit no extension events.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

os:macosIssues affecting macOS

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions