Eleven tabs, then zero: a path-separator bug in Orca

A remote client could see my Windows workspace but none of its eleven tabs. Changing only the path separators in the workspace ID reproduced it — so I filed the bug and sent the fix.

I run my coding agents in Orca. This morning a paired client could see one of my Windows workspaces but none of its tabs — eleven terminals and agent conversations, all still alive on the host, all invisible remotely.

The reproduction came down to one variable. Querying the host’s session.tabs.list with the same workspace ID, changing only the path separators:

worktree selectorTabs returned
id:repo-id::G:\git\example11
id:repo-id::G:/git/example0
path:G:/git/example11

Both requests succeed — the slash spelling just gets an empty snapshot instead of the existing one. Classic Windows: G:\git and G:/git are the same place everywhere except in an exact map-key lookup, and the explicit-ID fast path did exactly that, bypassing the resolver that knows better.

The bug report, with the 11-vs-0 reproduction table

Filed as stablyai/orca#27260, fix sent as #27264: resolve explicit session-workspace IDs with the existing worktreeIdsEqual comparison instead of exact keys, at every boundary that has to agree on workspace identity — listing, tab actions, terminal polling, subscription cleanup. The diff is +650/−32, and over 500 of those lines are tests.

Update (October 16): landed on Orca’s main via #29543 — a maintainer carried the commit with authorship intact, plus one review follow-up. Along the way another user hit the reverse direction (/ stored, \ requested); the fix compares IDs symmetrically, so it covers both. Shipped in v1.4.229 — reported against 1.4.224, fixed and released within a week.

Two months ago I would have restarted the app and moved on. The argo-cd incident seems to have permanently changed that default: reproduce it, file it, fix it.