Operating system
Windows 11 host + WSL2 Ubuntu 24.04 runtime
Orca version
1.4.173 (reproduced today; also affects panes created on much older builds)
Details
When OMP (omp, oh-my-pi) is launched by typing the command in a plain terminal pane (no agent launcher), Orca labels the tab ⠋ Pi / Pi ready and keeps that identity permanently — even though the managed status extension is correctly installed and posts to /hook/omp with agentType: "omp".
The contradiction is recorded in Orca's own state files on the same machine at the same time:
%APPDATA%\orca\agent-hooks\last-status.json — entries for these panes carry "agentType": "omp".%APPDATA%\orca\profiles\local-default\orca-data.json → workspaceSession.tabsByWorktree — the affected tab has no launchAgent field and "title": "⠋ Pi", while a tab created through the OMP launcher has "launchAgent": "omp" and shows OMP ready with identical hook traffic.- WSL-side
ps shows the transport working as designed: curl.exe ... -X POST ... http://127.0.0.1:<port>/hook/omp.
So the data path is healthy; the display layer overrides it.
Reproduction
CLI reproduction (what I ran, end to end):
orca terminal create --worktree current --json — plain shell tab, no agent launcher.orca terminal send --terminal <handle> --text "omp" --enter- Wait ~20s for the OMP TUI to come up.
orca terminal show --terminal <handle> --json → "title": "Pi" (spinner variant ⠋ Pi while working).
Control: create the tab through the OMP agent launcher instead — the tab persists "launchAgent": "omp" and displays OMP ready.
GUI equivalent: open a normal terminal tab, type omp, watch the tab label.
Expected behavior
- A pane whose status hooks post
agentType: "omp" is labeled OMP (tab, sidebar, status surfaces), regardless of how the process was started.
- Explicit hook identity outranks title-based inference.
Actual behavior
- The tab is labeled
⠋ Pi / Pi ready indefinitely. All subsequent agentType: "omp" status entries are rendered under the Pi label.
Analysis (from the shipped bundle)
Three mechanisms combine:
- OMP is a pi-mono fork and still sets its OSC 0 terminal title as
π: <session name> (DEFAULT_TERMINAL_TITLE = "π"). LEGACY_PI_COMPATIBLE_TITLE_RE (/^\s*(?:[\u2800-\u28ff]\s+)?π(?:\s*[-:]|\s)\s*.*$/u) classifies any such title as legacy Pi — by title alone, pi and omp are indistinguishable.
resolvePaneAgentOwner resolves the pane owner as launchAgent ?? startupLaunchAgent ?? initialStatusAgent ?? commandInferredAgent ?? hookAgent ?? .... For a typed launch there is no launchAgent, so the title-derived Pi identity is pinned as owner before/above the explicit hook signal.- Because
pi and omp share titleIdentityGroup: "pi-compatible", resolveCompatibleAgentTypeForOwner / normalizeCompatibleAgentStatusEntryForOwner deliberately rewrite every incoming agentType: "omp" entry to the pinned owner, so the correct hook identity can never win back the pane.
Suggested direction
Within the pi-compatible group, an explicit hook agentType should outrank (or re-pin) an owner that was inferred only from the legacy π title heuristic. Title evidence is inherently ambiguous between Pi and OMP; the hook payload is not. commandInferredAgent for a typed omp should also be able to correct the owner.
Related
Operating system
Windows 11 host + WSL2 Ubuntu 24.04 runtime
Orca version
1.4.173 (reproduced today; also affects panes created on much older builds)
Details
When OMP (
omp, oh-my-pi) is launched by typing the command in a plain terminal pane (no agent launcher), Orca labels the tab⠋ Pi/Pi readyand keeps that identity permanently — even though the managed status extension is correctly installed and posts to/hook/ompwithagentType: "omp".The contradiction is recorded in Orca's own state files on the same machine at the same time:
%APPDATA%\orca\agent-hooks\last-status.json— entries for these panes carry"agentType": "omp".%APPDATA%\orca\profiles\local-default\orca-data.json→workspaceSession.tabsByWorktree— the affected tab has nolaunchAgentfield and"title": "⠋ Pi", while a tab created through the OMP launcher has"launchAgent": "omp"and showsOMP readywith identical hook traffic.psshows the transport working as designed:curl.exe ... -X POST ... http://127.0.0.1:<port>/hook/omp.So the data path is healthy; the display layer overrides it.
Reproduction
CLI reproduction (what I ran, end to end):
orca terminal create --worktree current --json— plain shell tab, no agent launcher.orca terminal send --terminal <handle> --text "omp" --enterorca terminal show --terminal <handle> --json→"title": "Pi"(spinner variant⠋ Piwhile working).Control: create the tab through the OMP agent launcher instead — the tab persists
"launchAgent": "omp"and displaysOMP ready.GUI equivalent: open a normal terminal tab, type
omp, watch the tab label.Expected behavior
agentType: "omp"is labeled OMP (tab, sidebar, status surfaces), regardless of how the process was started.Actual behavior
⠋ Pi/Pi readyindefinitely. All subsequentagentType: "omp"status entries are rendered under the Pi label.Analysis (from the shipped bundle)
Three mechanisms combine:
π: <session name>(DEFAULT_TERMINAL_TITLE = "π").LEGACY_PI_COMPATIBLE_TITLE_RE(/^\s*(?:[\u2800-\u28ff]\s+)?π(?:\s*[-:]|\s)\s*.*$/u) classifies any such title as legacy Pi — by title alone, pi and omp are indistinguishable.resolvePaneAgentOwnerresolves the pane owner aslaunchAgent ?? startupLaunchAgent ?? initialStatusAgent ?? commandInferredAgent ?? hookAgent ?? .... For a typed launch there is nolaunchAgent, so the title-derived Pi identity is pinned as owner before/above the explicit hook signal.piandompsharetitleIdentityGroup: "pi-compatible",resolveCompatibleAgentTypeForOwner/normalizeCompatibleAgentStatusEntryForOwnerdeliberately rewrite every incomingagentType: "omp"entry to the pinned owner, so the correct hook identity can never win back the pane.Suggested direction
Within the
pi-compatiblegroup, an explicit hookagentTypeshould outrank (or re-pin) an owner that was inferred only from the legacyπtitle heuristic. Title evidence is inherently ambiguous between Pi and OMP; the hook payload is not.commandInferredAgentfor a typedompshould also be able to correct the owner.Related
agentType: "omp". This bug is the display layer discarding that corrected signal.