Skip to content

fix(orcad): provide the orca CLI in Windows managed-host terminals - #27324

Merged
OrcaWin merged 1 commit into
mainfrom
OrcaWin/orcad-windows-remote-cli
Oct 11, 2026
Merged

OrcaWin merged 1 commit into
mainfrom
OrcaWin/orcad-windows-remote-cli

Conversation

@OrcaWin

@OrcaWin OrcaWin commented Oct 10, 2026 •

Copy link
Copy Markdown
Collaborator
Files Added Deleted Net
Test 5 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​239 $\color{#cf222e}{\Huge{\mathbf{−}}}$​8 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​231
Prod 14 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​300 $\color{#cf222e}{\Huge{\mathbf{−}}}$​16 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​284

ELI5

On a Windows computer you reach over SSH, terminals that Orca's managed server (orcad) starts had no orca command. Linux and macOS servers have had one since #26539. This PR gives Windows servers the same command, so agents and people in those terminals can run orca status, orca orchestration send, and the rest.

Until now the old SSH relay supplied orca on Windows. The relay removal (#27214, #27215) takes that away, so this has to land first.

What Changed

What users see

  • Before: in a terminal on a Windows SSH host running orcad, orca was "not recognized", in cmd, PowerShell and Git Bash alike. Only relay-hosted terminals had it.
  • After: orca works in every orcad terminal on that host, whichever shell the host's OpenSSH DefaultShell picks. It runs the server's own CLI against that server's profile, exactly like the Linux and macOS launcher does. A multi-line or quote-heavy --body reaches the CLI unchanged.

Mechanism

  • The Windows desktop app already ships a small native launcher (native/windows-cli-launcher, the Rust orca.exe). The reason it exists is that cmd.exe re-parses %* and cuts a message at its first newline. The launcher now has a second mode: when an orca-launcher.cfg file sits beside it, it reads three lines (node=, cli=, user-data=). It then sets ORCA_USER_DATA_PATH, clears NODE_OPTIONS, NODE_REPL_EXTERNAL_MODULE and ELECTRON_RUN_AS_NODE, and starts pinned Node on the slot's CLI with each argument kept as its own argv entry. That is the same work the POSIX sh launcher does. With no config file, the desktop mode is unchanged.
  • The orcad template now ships bin/orca.exe for win32-x64 and win32-arm64 (ORCAD_WINDOWS_CLI_LAUNCHER_FILENAME). Because it is a slot artifact, it enters the version hash, the remote install probe and the template verifier. CI builds it on Windows runners through a new prepare-windows-cli-launcher action. arm64 is cross-compiled on the x64 template lane, the same way the process-table addon is. build-windows-cli-launcher.mjs gains --arch.
  • At startup orcad copies that exe into <profile>\cli\bin\orca.exe, only when the bytes differ, and writes the config beside it. A running orca keeps its image locked, so if that blocks the copy, the old exe is renamed aside and removed on a later start. This is the same stable profile path the POSIX launcher uses, so terminals that outlive a slot update still reach the new slot.
  • No change was needed in env injection: prependOrcaCliDirToChildPath already puts the launcher's directory first on Path and sets ORCA_CLI_COMMAND and ORCA_USER_DATA_PATH on Windows once a launcher exists. A new test pins that.

Authority: unchanged. The launcher only fixes the profile and strips Node and Electron preload variables. Terminal-scoped credentials still come from the terminal's environment, and the server still decides what each caller may do; desktop control stays blocked on orcad.

Why

  • Not a .cmd shim: cmd.exe re-parses %*, so newlines, %, ^ and quotes in a message body get cut or expanded. The desktop's orca.cmd refuses orchestration send/reply for exactly this reason. That would leave Windows servers below Linux and macOS.
  • Not a .ps1 or a PowerShell function: the default execution policy blocks scripts, cmd and Git Bash don't see them, and agent CLIs start orca through their own child shells. Bypassing the policy is an EDR signal we avoid.
  • Not compiling C# on the host, as the relay did: runtime-compiled MSIL is a behaviour Defender scores, and a managed orca.exe was flagged before ([Fixed - Verifying] [Bug]: Windows CLI launcher (resources/bin/orca.exe) quarantined as malware by enterprise EDR #23383). The native launcher was built to avoid that shape. It carries a version block and the orca.exe original filename, and is never renamed.
  • Reusing the existing launcher keeps one argv-preserving implementation instead of two.

None of this depends on relay code. The branch also merges cleanly onto #27214's client and server branches.

Linked Issue

Fixes #

Follow-up to #26539 (CLI on managed POSIX hosts); blocker for #27214 / #27215.

Visual Proof

N/A: there is no UI. The behaviour is a terminal command, and the Windows SSH host cells below are the proof.

Testing

  • orcad-cli-launcher.test.ts: on a Windows host, orcad installs orca.exe and the config that points at this slot, runtime and profile, with no .cmd or .ps1 beside it. It refreshes both on a slot switch, and a slot without the exe gets no command. Both install tests fail on main (expected null to be '…/cli/bin/orca.exe').

  • orca-cli-child-path.test.ts: Windows env injection (Path first, ; delimiter, no POSIX restore dir, profile and command set).

  • build-windows-cli-launcher.test.mjs (Windows, now registered in package_windows): builds the real launcher and runs it in server mode, from PowerShell with a multi-line body and directly with quotes, backslashes, %PATH% and ^. It checks argv, the profile override and the stripped NODE_OPTIONS/ELECTRON_RUN_AS_NODE.

  • orcad-windows-cli-launcher.test.mjs: template staging, PE machine check, and a refusal off Windows.

  • orcad-windows-host-lane.test.ts (SSH Windows host cells, x64/arm64 × inbox/preview, cmd and PowerShell DefaultShell): after a real deploy, <profile>\cli\bin\orca.exe status --json reports the runtime reachable and desktop control blocked.

  • Local: pnpm tc, pnpm lint, oxlint, check:code-quality:changed, focused suites.

  • I manually tested these changes locally

  • Automated tests added/updated, or explained why not below

AI Disclosure

Review

Agent skill upstream boundary

  • Not applicable, or this change copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

Ensure no issues in: Security, Cross-platoform support (Linux, Windows, Mac), Remote SSH, Mobile, general backwards compatibility, performance

  • Older desktops deploy their own templates, so mixed versions are unaffected. A slot without bin/orca.exe simply gets no command, the same as before.
  • The template's orca.exe is built in CI like the other template binaries. Whether release signing covers template contents is unchanged by this PR.

Checklist

  • This PR is small and focused
  • I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
  • Before/after screenshots or videos attached for UI changes, or N/A with reason
  • Self-reviewed for correctness, security, and performance
  • Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
  • pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)

@coderabbitai

coderabbitai Bot commented Oct 10, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration
  • Configuration used: Repository UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 6601c300-3556-44dd-8fa8-72d36cf836ba

📥 Commits

Reviewing files that changed from the base of the PR and between 35aeef8 and 858d78c.


📒 Files selected for processing (2)
  • .github/workflows/pr.yml
  • config/scripts/pr-code-change-scope.mjs

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.



📝 Walkthrough

Walkthrough

The change adds x64 and arm64 build support for the Windows CLI launcher and stages the launcher with Windows OrCAD artifacts. On Windows, OrCAD setup writes the Node, CLI, and user-data paths to a config file. The native launcher reads this config and runs the configured CLI. Windows workflows prepare or transfer the launcher for builds and tests. Added tests cover architecture selection, staging, configured execution, and Windows host behavior.


Priority: ➖ Normal

Merge Risk: ⚪ Minimal · up to 858d7

The changes add the Windows launcher build test to the relevant classification and test run; no actionable merge-blocking risk remains.

Pre-merge checks | Passed 3 | Failed 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Description check Warning The description is detailed and covers the user impact, implementation, rationale, testing, security, compatibility, and checklist items. The required Linked Issue field is incomplete because it conta… Replace Fixes # with the actual issue reference, or document the maintainer exception if no new issue is required.
Docstring Coverage Warning Docstring coverage is 19.05% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 21 functions across 13 files. (1 skipped:… Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (3 passed)
Check name Status Explanation
Title check Passed The title clearly identifies the main change: adding the Orca CLI to Windows managed-host terminals.
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description is detailed and covers the user impact, implementation, rationale, testing, security, compatibility, and checklist items. The required Linked Issue field is incomplete because it contains only Fixes #, although related issue references appear elsewhere.


Full details: Docstring Coverage

Explanation

Docstring coverage is 19.05% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 21 functions across 13 files. (1 skipped: 1 unsupported.)


  • Fix all pre-merge checks with AI
✨ Finishing Touches 💡 1
📝 Generate docstrings 💡
  • Commit to this branch
  • Create a new PR


  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
.github/actions/prepare-windows-cli-launcher/action.yml (1)

33-38: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Reject unknown architectures before rustup target add.

An unknown arch value makes $triples[$arch] evaluate to $null. In that case, rustup target add runs with no target and fails with an unclear usage error. Add an explicit check. The build script already rejects unsupported architectures, but that check runs after the rustup step.

Proposed fix
         foreach ($arch in ($env:ARCHES -split ' ' | Where-Object { $_ })) {
+          if (-not $triples.ContainsKey($arch)) { throw "Unsupported Windows CLI launcher arch: $arch" }
           rustup target add $triples[$arch]

ℹ️ Review info
⚙️ Run configuration
  • Configuration used: Repository UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: ea070778-3062-485c-beb2-535e9a213812
📥 Commits

Reviewing files that changed from the base of the PR and between 68519e6 and f834e30.

📒 Files selected for processing (19)
  • .github/actions/prepare-windows-cli-launcher/action.yml
  • .github/workflows/e2e.yml
  • .github/workflows/node-server-tests.yml
  • .github/workflows/pr.yml
  • .github/workflows/ssh-windows-hosts.yml
  • .github/workflows/win-orcad-serve-switch-e2e.yml
  • config/scripts/build-orcad.mjs
  • config/scripts/build-windows-cli-launcher.mjs
  • config/scripts/build-windows-cli-launcher.test.mjs
  • config/scripts/node-server-change-scope.mjs
  • config/scripts/orcad-windows-cli-launcher.mjs
  • config/scripts/orcad-windows-cli-launcher.test.mjs
  • config/scripts/pr-code-change-scope.mjs
  • native/windows-cli-launcher/src/main.rs
  • src/main/cli/orca-cli-child-path.test.ts
  • src/main/orcad/orcad-cli-launcher.test.ts
  • src/main/orcad/orcad-cli-launcher.ts
  • src/main/ssh/orcad-windows-host-lane.test.ts
  • src/shared/orcad-artifacts.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

@OrcaWin
OrcaWin force-pushed the OrcaWin/orcad-windows-remote-cli branch from f834e30 to 35aeef8 Compare October 10, 2026 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant