Repository navigation
fix(agents): an old Windows or unknown-platform host asks to update instead of answering its default list - #27164
Conversation
…nstead of answering its default list A host without preflight.workspace-scoped.v1 answers a workspace's agent request with its own default list. On a Windows host that list misses a WSL workspace's agents, and a host that does not report its platform may be Windows. Only a known non-Windows host's default is still used; the others record an empty list plus an update notice, shown in the quick-launch menu. Co-Authored-By: Claude <noreply@anthropic.com>
Reading the platform from the shared capability cache could see a probe another caller had just started (no status yet) and flag a Linux host. A fresh status is race-free and also catches an in-place upgrade. Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to No actionable merge-blocking issue is established for the workspace-agent update notice. The change is mergeable after normal checks. Pre-merge checks |
|
ELI5
When you open the agent menu for a workspace that lives on another Orca server, Orca asks that server which agents the workspace can use. Older servers cannot answer for a specific workspace, so they answer with the agents of the server itself. On Windows that is often the wrong list: a workspace running inside WSL has its own agents. Now Orca only trusts that fallback list when it knows the server is not Windows; otherwise it shows "Update Orca on this server to list this workspace's agents".
What Changed
preflight.workspace-scoped.v1) answered every workspace with its machine-wide default list. For a Windows server with a WSL workspace, the quick-launch menu listed native Windows agents that would not launch in the workspace, and missed the WSL ones. The same happened for a server that does not report its platform at all.callRuntimeAgentDetection(renderer store,runtime-detected-agents.ts) already checks the capability before sending a workspace-scoped request. When the cached verdict says the capability is missing, it now fetches a freshstatus.get(only for such old servers) and decides from that one answer: capability present after all (in-place upgrade) → scoped request;hostPlatformknown and notwin32→ the default list as before; otherwise a typedRuntimeAgentDetectionNeedsServerUpdateError. The slice commits that as[]+runtimeAgentDetectionNeedsServerUpdate[key], whichuseDetectedAgentsexposes asneedsServerUpdate. The flag is dropped with its environment like the other per-key records. A fresh status is used instead of peeking at the shared capability cache because a concurrent probe can leave that cache without a status for a moment, which would wrongly flag a Linux server.Why
hostPlatformis optional in the status contract, so absence cannot be read as "not Windows"; failing closed with a clear update prompt is safer than offering agents that may not exist where the workspace runs. Alternatives considered: guessing the workspace's runtime from its path (rejected — a guess, and the server owns that decision), or keeping the default list with a warning (rejected — users would still launch agents into the wrong runtime). No wire change: only the client's reading of an existing optional field changes.Linked Issue
None — part of the host-routing design stack (slice D4-S10).
Visual Proof
N/A — the only visible change is the disabled menu row text for old Windows/unknown-platform servers; covered by store tests.
Testing
New
src/renderer/src/store/slices/runtime-detected-agents.test.ts: old Windows host and no-platform host → empty list + update flag, no agent request sent; refresh replaces a cached list; old Linux host still gets its default; host default (no workspace) unchanged; flag clears after the host gains the capability; concurrent workspaces on an old Linux host both get its default; flag dropped with its environment. The Windows/no-platform cases fail onmain(it returns the server default list).Focused suites:
store/slices,runtime,components/tab-bar,hooks, i18n — all pass exceptSortableTab.rename-shortcut.test.tsx, which fails identically onmain(lucide mock).pnpm tc:web, oxlint,pnpm run check:code-quality:changedpass.I manually tested these changes locally
Automated tests added/updated, or explained why not below
Review
Agent skill upstream boundary
Notes
Cross-platform: the rule is about the server's reported platform, not the client's. SSH workspaces are untouched (they use the SSH detection path). Folder workspaces go through the same workspace-scoped key. Mobile is unaffected (separate detection code). Backwards compatibility: new servers are unaffected; old non-Windows servers behave as before.
Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)