Myles AndersonandClaude Opus 5.5
2c63f548c2
* Open the macOS app's dashboard in its own window The OpenResearch.app now hosts the dashboard in a native window (tao + wry WKWebView) instead of handing it to the user's browser. It adds a standard menu bar, save panels for downloads, a native window.confirm panel, and a Cmd+Q that flushes workspace state and shuts the server down cleanly. Pop-ups open in the system browser (http/https/mailto only). The app now prefers port 4792 so the window's localStorage survives relaunches. The Dock-click tab-focus script, its Apple-events entitlement, and the SSE client counter it relied on are removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Open the dashboard in its own window on Windows Adds the Windows desktop app. A small GUI-subsystem OpenResearch.exe (windows/launcher) starts the orx.exe beside it as `orx app` in a hidden console, so orx and the git, shell, and agent processes it runs share one invisible console instead of each flashing a window. `orx app` shares the macOS window code in src/commands/app.rs: WebView2 window, pop-ups to the system browser, save panel, page-load reveal, and port 4792. On Windows, closing the window quits, a second launch focuses the running window (named mutex + event), and the taskbar groups the window with the Start menu shortcut. An update restart relaunches as the app on the same port. Quit on both platforms now goes through up::request_shutdown instead of a self-sent SIGTERM. An Inno Setup script builds a per-user OpenResearch-Setup.exe with a Start menu entry and a WebView2 bootstrap. CI builds it as an artifact, and release-windows-app.yml attaches it to releases once WINDOWS_APP_ENABLED is set. The icon is embedded via embed-resource. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Fix the Windows build and address review of the Windows app - The focus listener captured its bare HANDLE (edition 2021 disjoint capture) instead of the Send wrapper, which failed to compile on Windows. - An orx.exe away from the CLI installer's prefix, like the app's, is now Portable even when the installer's receipt exists, so it can update itself. - Single instance creates its event before the mutex; the launcher hands its foreground rights to orx.exe. - Focus requests and server readiness are ignored while quitting, and focus waits for the first load. The save dialog is owned by the window. - Telemetry counts an app start only after the instance claim. - The installer reports a failed WebView2 bootstrap and shows progress. - Icon embedding now fails the build if no resource compiler is found. - CI format-checks the launcher; the release job drops an unpinned action. - Docs: maintainer notes for the release gate, two known gaps, and wording. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tighten the Windows app after a second review - Keep the macOS save panel free-floating: only Windows gets the window as its owner, since a parent makes rfd show a sheet on macOS. - Treat the WebView2 bootstrap as failed unless the runtime is then present. - Move the UTF-16 helper out of the single-instance module, and bind the kernel object names before the mutex call that GetLastError follows. - Docs and a dead_code reason. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Show a stalled app window, and close the app before the installer runs If the dashboard never finishes loading, show the window 15 seconds after the server is up and say so on stderr; a relaunch (or a Dock click on macOS) also shows it before the page loads. The installer and uninstaller now check the app's single-instance mutex and ask the user to close it, rather than replacing files under a running app and skipping its shutdown path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Keep a replaced download's original until it lands, and don't offer a launch without WebView2 Move the file a download replaces aside and restore it if the download fails or is cancelled (WebView2's flyout can cancel), rather than deleting it up front. The installer no longer offers to start OpenResearch when the WebView2 Runtime is still missing, since the window could not open. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
5.2 KiB
Windows
Windows support is in beta. The CLI and dashboard work, including local experiment runs and the nanochat demo. The gaps are listed at the bottom.
Prerequisites
Git for Windows is required, and for more than git. It is the only source of
the bash and coreutils that orx uses to run experiments — the bash.exe in
System32 is the WSL launcher, which cannot see your files, and orx rejects it.
Install it with the standard installer so git.exe lands on PATH; orx finds
the shell by walking up from there.
You also need a coding agent. Claude Code is the default:
winget install --id Git.Git -e
winget install --id OpenJS.NodeJS.LTS -e
npm install -g @anthropic-ai/claude-code
Open a new terminal afterwards so PATH is picked up.
The nanochat demo installs uv, and with it Python, on its first run.
Install
The desktop app
From Releases, download
OpenResearch-Setup.exe and run it. It installs for your account only, with no
administrator prompt, into %LOCALAPPDATA%\Programs\OpenResearch, adds
OpenResearch to the Start menu, and installs the Microsoft Edge WebView2 Runtime
if Windows lacks it. The dashboard opens in its own window; closing the window
quits OpenResearch, and starting it again while it runs brings the window back.
Running the installer or uninstaller while OpenResearch is open asks you to
close it first.
The install holds two programs. OpenResearch.exe is what the Start menu runs:
it starts orx.exe app in a hidden console, which orx and the git, shell, and
agent processes it starts share, so none of them flashes a window. Agents find
orx because its folder leads their PATH. orx.exe is the same binary as the
CLI release and updates itself the same way (below).
The app uses port 4792, or a free port if something else holds it.
The CLI
From Releases, download
openresearch-cli-x86_64-pc-windows-msvc.zip, extract it, and double-click
orx.exe. It starts the dashboard at http://127.0.0.1:4791 and opens your
browser. Leave the console window open — closing it stops the server. If orx
cannot start, a dialog says why.
To have orx on your PATH as a command instead, run the PowerShell installer,
which installs to %USERPROFILE%\.cargo\bin:
powershell -ExecutionPolicy Bypass -c "irm https://github.com/alphaXiv/OpenResearch/releases/latest/download/openresearch-cli-installer.ps1 | iex"
Every install updates itself. orx update, or the Updates section of the
dashboard's Settings page, replaces orx.exe in place, and a running dashboard
offers a Restart button once the new version is on disk. The app's launcher
changes only with a new OpenResearch-Setup.exe.
The SmartScreen warning
Neither orx.exe nor the installer is code-signed yet, so Windows shows
"Windows protected your PC" on first run. Choose More info → Run anyway.
Signing is planned, but it will not make this go away immediately: since 2024 even an EV certificate has to earn SmartScreen reputation through download volume like any other, so early builds will keep showing the warning.
Long paths
Windows refuses paths over 260 characters. orx passes core.longpaths to git
itself, but a deep repository can still defeat the agent or your experiment
scripts. If you hit "path too long" from something that is not git, enable long
paths system-wide — once, as administrator, then reboot:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Value 1
Known gaps
orx up --remote-host |
Refused. The control channel is a Unix domain socket. |
| Restart after an update | There is no exec, so a restarting orx up starts a new process and exits. In a terminal the prompt comes back while the server keeps running in that console, where Ctrl+C still stops it; a supervisor sees the old process exit. |
| SSH connection reuse | Windows' OpenSSH cannot multiplex, so each status or log poll opens its own connection, and the Settings page uses the most recent preflight result instead of reporting a missing multiplexed master as a disconnection. Use a key held by an agent, or one without a passphrase. |
| The PATH guard | Not applied; it needs a POSIX shell startup file. |
| Data directory | Still %USERPROFILE%\.local\share\openresearch, not %APPDATA%. |
| Signing out or upgrading while the app runs | Windows ends the app at once, without stopping the agents it started or saving the last workspace state. |
| Starting the app while it is quitting | The new launch finds the old one still running and exits, so start it again once it has closed. |
Releasing the app
release-windows-app.yml builds OpenResearch-Setup.exe from each release's
published orx.exe and attaches it, once the repository variable
WINDOWS_APP_ENABLED is true. Like the macOS app it follows a Release run
dispatched by a token (see macos/DISTRIBUTION.md); to attach the installer to
an existing release, dispatch the workflow with its tag. CI on every pull
request also uploads an openresearch-windows-installer artifact to test with.