OpenResearch keeps experiments attached to the agent that ran them
Ask a coding agent to try another experiment and you soon need somewhere to keep the previous result. OpenResearch provides that workspace: it records experiments in a local SQL database and keeps code, logs, and artifacts on your machine. Its README names literature connections to alphaXiv, bioRxiv, and PubMed. The useful promise is being able to inspect what an agent did before letting it choose the next experiment.
The requested repository, alphaXiv/openresearch-cli, now redirects to alphaXiv/OpenResearch, whose README recommends the desktop app. Our measured checkout was commit 951700e: 550 files, roughly 168,609 source lines, and 12.1 MB before installation. Keep that distinction in mind. The source run below concerns that commit, while current platform guidance comes from the live documentation. We have no desktop usability or research-quality measurement to attach to it.
What happened when we ran it
Our run installed OpenResearch's 250 packages in 12 seconds and built it successfully in 148 seconds. We cloned commit 951700e on October 6, 2026, into a fresh Debian sandbox using image lab-rust:1, with 3 CPUs and 12 GB of RAM. The container was unprivileged and held no secrets. These results show that the measured source setup completed its install and build steps in that environment.
Cargo tests failed with exit 101 after 111 seconds. The lab's aggregate reports 2,056 passed and 8 failed out of 2,064. The final binary-suite summary is narrower: 1,028 passed, 4 failed, and 3 ignored. Those are different scopes in the supplied record. Reporting only the final four failures would understate the full result, while claiming eight distinct diagnosed defects would go beyond the evidence.
The visible panic came from interactive_login_removes_orphaned_sockets_and_broken_symlinks: SSH configuration resolution returned No user exists for uid 1000, then the test unwrapped that error. The other named failures concern existing SSH keys, prepared routes, and shared-file installation. The tail does not explain each failure. It establishes a Unix-user lookup problem in one case, without proving that every failure shares that cause or that real SSH sessions fail identically.
Existing agents and compute accounts still do the work
OpenResearch works with Claude Code and other coding agents, and its local-model guide routes local inference through OpenCode. You still need an agent and a usable model. A cloud provider needs its own authentication, while the documented local-model route needs no cloud account. SSH requires access to your host, and managed OpenResearch compute uses an OpenResearch account. Choosing a workspace doesn't provision those services for you.
The local-model guide requires a tool-capable model and a loopback endpoint. Inference on another machine therefore needs forwarding or a server beside the remote OpenResearch process. Our 12 GB sandbox allocation says nothing about which model will fit your machine. Paper searches and agent commands can still use the network, so local inference alone doesn't make the whole research workflow offline.
Windows remote-host mode is unavailable
The Windows guide explicitly refuses orx up --remote-host because its control channel uses a Unix domain socket. Windows also requires Git for Windows for Bash and coreutils, and its SSH client cannot reuse multiplexed connections. If your Windows workstation must control the remote-host mode, this is a reason to choose another arrangement before moving your research into the app. The README labels Windows support beta.
Linux desktop users need glibc 2.35 or newer and FUSE support, with an extract-and-run option where FUSE is unavailable. The Linux guide also documents missing bundled media support and certificate-path trouble for embedded HTTPS pages on Fedora and openSUSE. These desktop requirements are separate from our successful 148-second source build. A headless CLI build cannot establish that an AppImage displays your artifacts correctly.
Agent feedback needs a separate privacy decision
The current README says official releases send coarse analytics and detailed agent feedback tied to a random installation ID. It says sensitive content is excluded and agents are instructed to sanitize reports. Both can be disabled in Settings or with orx telemetry off. For confidential research, make that choice before starting a session. The assurance that project files stay local doesn't remove the separate feedback channel.
Our checkout contained 12 CI workflow files and a tests directory, with no Dockerfile found. That gives a contributor places to inspect the upstream checks, but our 8 failed tests remain the result for the measured container. Neither the workflow count nor the successful build establishes whether telemetry filtering, remote cancellation, or artifact handling meets your institution's requirements.
October activity includes unresolved workflow reports
GitHub recorded a push on October 15, 2026, and 108 open issues and PRs. Release v0.2.18 arrived on October 9. Recent issue updates and merged work accompany that push, so there is evidence of ongoing maintenance beyond the release tag. The release notes include fixes for disappeared remote jobs and concurrent-process file handling, areas that matter when experiments run unattended.
Open issue 637 reports that work in version 0.2.16 accumulated in internal worktrees while the selected project folder stayed unchanged. Open issue 627 describes a misleading remote-binary rejection diagnostic. These are specific user reports, separate from our 111-second failing test run. Before entrusting a long experiment, confirm where its output lands and how your remote installation reports failures. I'd adopt OpenResearch for inspectable agent experiments only after checking those paths with expendable work.