[Bug]: Desktop client paired to a remote runtime never mirrors a workspace created after the client connected (tabs and agent rows missing until reload)
- Dominant language
- TypeScript
- Stars
- 72.1k
- Forks
- 4.7k
- Avg merge
- 14h 54m
- Merged PRs (30d)
- 520
Description
### Operating system
macOS (both sides)
### Orca version
1.4.197 on both the host and the client
### Details
**Setup.** Host: a desktop Orca broadcasting itself as a Remote Orca Server. Client: a second desktop Orca reaching it through a saved environment. One paired desktop client; a mobile client exists but was not open.
**Short summary.** A workspace (git worktree) that the host creates *after* the desktop client connected shows up in the client's sidebar, but the client never mirrors its tabs or agent rows. Selecting it shows an empty tab strip. A sibling workspace in the same repo that existed *before* the client connected mirrors fine. `View → Force Reload` on the client fixes it instantly; so does restarting the client.
**What happened.**
1. Client connected at 13:41Z. Workspace `main` of the repo existed already; the client mirrored its two terminal tabs and showed two agent rows.
2. At 14:44Z the host created workspace `spec-7` in the same repo and launched an agent in it. The client's sidebar gained the `spec-7` row (the catalog refresh works), but no agent row and no tabs, for 27 minutes.
3. At 15:11:54Z the user pressed Force Reload on the client. The workspace rendered immediately: three tabs and the agent rows appeared.
**Evidence.**
- Host projection was complete the whole time. `session.tabs.listAll` over the runtime socket returned the workspace with its tabs and agent status, agreeing with `orca worktree ps --json` and the hook store.
- The client's main process had the same data: `orca terminal list --environment --json` on the client listed the same handles, titles and `lastOutputAt` as the host.
- The client's renderer never applied a snapshot before the reload. In the client's persisted `orca-data.json`, `workspaceSessionsByHostId["runtime:"]` had `tabsByWorktree` / `unifiedTabs` / `tabGroups` entries for `main` and none for `spec-7`, although `lastVisitedAtByWorktreeId` recorded the user selecting `spec-7`. After the reload, `tabsByWorktree` for `spec-7` holds the three `web-terminal-*` tabs.
- Transport was healthy: two ESTABLISHED sockets on the host, the client's device row in the host's `orca-devices.json` kept advancing `lastSeenAt`, and `orca status --environment ` on the client reported ready/reachable. The environment card was not dimmed (so `runtimeStatusByEnvironmentId` was not null and the mirror was mounted, since `main` kept updating).
**Side effect (#17681).** Because the client's local terminal count for the workspace stays 0, `shouldBootstrapInitialWebRuntimeTerminal` fires on every focus. Nine plain shells were created on the host in 18 seconds while the user clicked the workspace. Details are in my comment on #17681.
**Where it may come from.** `subscribeSessionTabsInventory` (`src/main/runtime/rpc/methods/session-tabs-inventory.ts`) subscribes to `onMobileSessionTabsChanged` for every workspace, so the host does push `updated` frames for the new workspace. Since a fresh subscription that sees the workspace in its initial `snapshots` inventory applies fine, the drop is on the client between `handleGlobalSessionEvent` (`src/renderer/src/runtime/web-session-tabs-sync/global-session-events.ts`) and the store patch, for a workspace that was not in the inventory when the subscription started. Candidates I could not distinguish without the renderer console: the visibility-resume inventory fence (`VisibilityResumeCoordinator.shouldApplySnapshot`), the freshness gate (`decideWebSessionTabsSnapshot`), or `recoverWebSessionTerminalOrphansBeforeApply` returning nothing.
**How to reproduce.**
1. Pair a desktop Orca to a Remote Orca Server (another desktop, or `orca serve`).
2. With the client connected, create a new worktree on the host and start an agent in it (I used the host's own orchestration; a manual `orca terminal create --worktree --command ` on the host should do).
3. On the client, watch the new workspace row: no agent row appears, and selecting it shows an empty tab strip. Do not click it more than needed, each focus seeds a shell on the host (#17681).
4. `View → Force Reload` on the client: tabs and agent rows appear.
**Expected.** A workspace the host creates while a client is connected mirrors on that client like any pre-existing workspace, without a reload or restart.
Contributor guide
Assessment
This issue has not been assessed yet.