[Bug]: With multiple opencode TUIs running, agent state/prompt/spinner/notifications are attributed to the wrong worktree card #24844

Environment

• Orca desktop + CLI: 1.4.217 (Windows 10, 10.0.19045), local host
• Agents: opencode TUI, two instances running at the same time in different worktrees (plus a few idle ones in other projects)
• Observed: 2026-10-02, ~16:00–16:35 local

Summary

With two or more opencode TUI sessions running in different worktrees, Orca attributes the working state, the typed prompt, the card spinner and the "… now" activity line of the active session to another worktree's card. orca worktree ps reports the state/prompt of session A under session B's worktree, while B's terminal actually shows B's own long-finished turn. Sidebar marks/notifications therefore keep landing on projects where nothing is running.

Reproduction (captured live today)

Setup:

• Worktree A: D:\Projects\VibeCoding\popizdelki (repo 1b7e9cde…), terminal titled OC | Возможности MCP hapy. Session A is an opencode TUI actively processing turns (Plan mode, glm-5.3-flash).
• Worktree B: D:/Projects/Hybrid/panelapps_core/.agents/worktree/CON-12617-lookalike-host (repo ac4a408b…), terminal titled OC | Изучение спеки в openspec. Session B is an opencode TUI whose last turn finished minutes earlier (its screen shows Build · glm-5.3 · 3m 19s and an old answer about a LAL audience E2E).

Steps:

1. Keep both opencode TUIs open in their worktree terminals.
2. In session A (worktree A), send a new prompt (e.g. Поставь, но что то я ничего не понял…).
3. While A is working, run orca worktree ps --json.

Actual result — worktree ps lists under worktree B:

"repo": "panelapps_core",
"displayName": "feature/7.0/CON-12617-lookalike-host",
"agents": [{
  "agentType": "opencode",
  "state": "working",
  "prompt": "Поставь, но что то я ничего не понял, я запустил новый тер…",
  "lastAssistantMessage": null
}]

…i.e. session A's fresh prompt and working state are attributed to worktree B, while:

• orca terminal read of B's PTY shows B's own old, finished conversation (no input box text matching that prompt);
• orca terminal read of A's PTY shows session A's TUI actively rendering that very turn;
• orca worktree current run from session A's shell resolves worktree A correctly (cwd-based), contradicting ps.

The sidebar mirrors the wrong attribution: the spinner and the "… now" activity line appear on B's card, A's card shows nothing. The user sees "work" happening in an unrelated project. The auto-title of B's terminal also flipped from OC | Изучение спеки в openspec to Terminal 2 during the same observation window, so the detection seems to flip-flop rather than being pinned to a pane.

Secondary observation from the same session: the sortOrder of all 20 registered worktrees (including inactive ones with zero live terminals) was re-stamped inside one ~19 s window at exactly 1000 ms increments, uncorrelated with any real activity — consistent with presence/activity state being recomputed from a shared, misattributed source rather than per pane.

Expected

Agent presence (working/done, prompt text, spinner, activity lines, notifications) is tracked per terminal pane and attributed to the worktree that owns that pane, regardless of how many opencode TUI instances are running.

Impact

• Sidebar marks, spinners and "finished"/activity notifications land on unrelated projects — the user cannot trust the sidebar to see where work is running.
• orca worktree ps output (prompt/state per worktree) is wrong, which misleads automation and orchestration built on the CLI.

Notes / possibly related

• fix(desktop): use host-owned agent presence (step 2 of 3) #24175 fix(desktop): use host-owned agent presence (step 2 of 3) — the list of views that "guess" agent presence (sidebar activity and sort order, workspace dots, notifications) matches this report; this issue looks like another symptom of the same subsystem, specifically the cross-worktree/pane misattribution with multiple opencode TUIs.
• fix(opencode): clear an opencode run row when its process exits #24292 fix(opencode): clear an opencode run row when its process exits — also touches stale opencode rows in worktree ps.
• The v1.4.218 release notes do not mention a fix for this.