Repository navigation
[Bug]: Windows SSH PTYs can lose the deployed Orca CLI from Path #22110
Description
Operating system
Windows
Orca version
Current main source build at 15472cd4c61e64beaec1eb825372ffd8928d5342.
Details
Short summary
A native Windows PowerShell or cmd PTY opened through Orca's SSH relay can receive ORCA_REMOTE_CLI_BIN_DIR while its effective case-insensitive Path still omits that directory. The deployed remote orca CLI bridge then cannot be resolved from the PTY.
What happened?
During a real Windows 10 x64 SSH relay/ConPTY validation, the relay and remote CLI bridge deployed successfully, but the native PTY could not invoke orca. The relay builds the final environment by combining its inherited Windows environment with the client-provided environment. Windows treats PATH and Path as the same variable, while the JavaScript object can carry different casing, so the value that reaches the native shell can lose the bridge directory.
WSL panes should not receive the Windows launcher path because their executable environment is owned by the Linux guest.
How can we reproduce it?
- Connect Orca to a native Windows SSH host.
- Let Orca deploy its remote relay and CLI bridge.
- Open a native PowerShell, PowerShell 7, or cmd PTY through the relay.
- Inspect the effective
Pathor invokeorca. - The bridge directory from
ORCA_REMOTE_CLI_BIN_DIRmay be absent, soorcais not found.
Expected behavior
Immediately before spawning a native Windows PowerShell or cmd PTY, prepend ORCA_REMOTE_CLI_BIN_DIR to the effective case-insensitive Path, without duplicating an existing entry. Leave WSL launch behavior unchanged.
Validation evidence
The failure was reproduced with Orca's real SSH relay and ConPTY on Windows 10 x64. A candidate fix restored CLI discovery in the native Windows PTY. Focused tests cover Windows PowerShell, PowerShell 7, cmd, case-insensitive PATH/Path, duplicate removal, and the WSL exclusion.
Activity
AmethystLiang commentedon Sep 22, 2026
thanks for reporting. looking into it
abruption commentedon Sep 27, 2026
Thanks for looking into this. I submitted #22112 as a focused fix for this issue: it prepends the deployed CLI bridge directory to the effective Windows Path immediately before native PowerShell/cmd PTY launch, with case-insensitive deduplication and no Windows path injection into WSL.
Validation included 29 focused tests, Node typechecking, and a real Windows 10 SSH/ConPTY run with PowerShell 7 that restored CLI discovery. The WSL validation also passed. Stock PowerShell 5.1 end-to-end bootstrap remains unverified on that host because its policy rejected the compressed bootstrap before PTY launch; the shell launch logic has unit coverage.
This was discovered while validating the separate terminal-mailbox subscription work in #22115. The Windows Path fix is split into #22112 so it can be reviewed independently. Maintainer review would be appreciated.
OrcaWin commentedon Oct 11, 2026
Thank you @abruption for the careful report and for #22112. Orca's SSH relay has been retired (#27214, #27215): SSH hosts now run Orca's managed server, and #27324 gives Windows hosts a native
orca.exelauncher that is prepended to the terminal'sPathusing the case-insensitive key, so native PowerShell and cmd terminals findorca. Closing as fixed — please reopen if you still see it on a current build.