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>
OpenResearch
The local-first workspace for research agents and autoresearch.
Turn 
Claude Code,
Codex,
OpenCode,
Cursor, or Google Antigravity into research agents that can review
literature, develop hypotheses, run experiments, and produce research artifacts.
macOS 11+ · Windows beta requires Git for Windows
Get started
Install the CLI on macOS or Linux, then launch OpenResearch:
curl -LsSf https://openresearch.sh/install.sh | sh
orx up
orx up opens the local dashboard at http://127.0.0.1:4791.
On a managed Mac (for example, a work computer), use the macOS download above
instead. Device-management policies may block the CLI that install.sh
installs because it is not yet signed. The app is signed with a Developer ID
and notarized by Apple. To use orx in your terminal, click Install under
Install the orx command in the app's Settings → Updates, or run (adjusting
the path if the app is not in /Applications):
/Applications/OpenResearch.app/Contents/MacOS/orx install-cli
Either way, orx is linked into ~/.local/bin, with a hint to add it to your
PATH if needed. If you already ran install.sh, remove ~/.cargo/bin/orx
first and open a new terminal.
On Windows, use the beta download above after installing Git for Windows.
Connect a local model to use LM Studio, oMLX, Ollama, or a custom endpoint with OpenCode.
Create an account at openresearch.sh to receive email updates and use managed OpenResearch compute.
Built for research agents
| OpenResearch gives you | |
|---|---|
| Parallel exploration | Give each research direction an independent agent session and isolated git worktree. |
| Reproducible experiments | Track variants in a git-native experiment tree; every run receives an immutable archive of its recorded commit. |
| Evidence in context | Keep logs, diffs, files, results, and artifacts tied to the work that produced them. |
| Your choice of agent | Use Claude Code, Codex, OpenCode, Cursor, or Google Antigravity, with the harness and model selected per session. |
| Your choice of compute | Run locally, on your own infrastructure, or with managed OpenResearch compute. |
| Local ownership | Keep projects, conversations, experiments, runs, logs, code, and artifacts on your machine. |
Autoresearch
OpenResearch can run the full loop autonomously: propose an idea, change the code, launch an experiment, inspect the evidence, and decide what to try next. Multiple agents can explore different directions in parallel while the experiment tree preserves their lineage.
Run anywhere
The same committed source snapshot can run locally, over SSH, or on Slurm, Kubernetes, Ray, Hugging Face Jobs, Modal, Tinker, and managed OpenResearch compute. Publishing the repository is not required.
Run the workspace next to remote GPUs while using the browser on your laptop:
orx up --remote user@host
SSH config aliases and custom ports are supported. The remote service binds to loopback and has no application-level authentication, so other users on that host can reach it.
CLI and agent integration
Install the OpenResearch skill into supported coding agents:
orx install-skills
Common commands:
orx projects
orx project view <project-id>
orx runs <project-id>
orx logs <run-id>
orx exp run <experiment-id>
orx discover keyword <query>
orx paper <arxiv-id-or-doi>
Run orx --help or orx <command> --help for the complete interface.
Local by default
OpenResearch runs on 127.0.0.1 with a local SQLite store. Creating a project
or launching a run does not publish your code. An
openresearch.sh account is only used for
service-owned capabilities such as organizations and managed compute.
Usage analytics
Official release builds send opt-out, coarse usage events tied to a random installation ID. They do not include code, prompts, file contents or paths, repository names, tokens, emails, or project and experiment identifiers.
orx telemetry off
orx telemetry status
orx <command> --no-telemetry
Source and development builds do not send analytics.
Coding agents may also file product feedback with orx feedback when you hit
a bug, wish for a feature, or get frustrated with OpenResearch. Each report is
a short description of the workflow problem, written to omit your research
details. Like analytics, reports are sent only from official release builds.
They are linked to your account when you are logged in and turned off by
orx telemetry off. The --no-telemetry flag covers only the command it is
passed to.