Open Science v0.25.1 combines agents, notebooks, and provenance
Open Science v0.25.1 is an Electron desktop application built around research projects rather than isolated chat threads. A session can ask an agent to read files, search, call connectors, run code, and create reports or figures. Generated artifacts are stored as immutable, checksummed versions tied to available inputs, execution history, environment details, and the conversation branch that produced them. Missing evidence is labeled unavailable instead of being filled in, a sensible boundary for scientific work.
The application supports Python and R notebooks, but notebook execution is optional during its 5-step onboarding. Projects retain uploads, generated files, previews, tool calls, and message branches across restarts. The preview panel understands scientific data, office documents, images, source code, molecular structures, and notebook history. These pieces make Open Science more useful than a generic chat window when the task creates files that someone must inspect later. They do not establish that the scientific conclusion is correct.
Twenty-four connectors widen access and the data-exposure surface
The current catalog lists 24 built-in research connectors and 22 featured skills. Connectors cover literature, genetics, proteins, clinical sources, chemistry, structures, expression data, and an offline molecule viewer. Custom MCP servers can use stdio, HTTP, or SSE, while connector and tool policies can require approval, allow a call, or block it. File-based skills can also arrive from GitHub or user packages after preview and confirmation.
Every external model, web search, and connector creates its own data boundary. Open Science stores projects and configured credentials locally by default, yet the README says content needed for provider or connector calls can leave the machine. Three approval profiles range from asking before edits and network calls to full access. Researchers handling patient data or unpublished results should map each provider and connector before turning on broad approval, regardless of the local-first label.
What happened when we ran it
Our sandbox installed 1,682 npm packages in 113 seconds and occupied 2,220 MB on disk. The build completed successfully in 238 seconds. This was a large checkout even before dependencies: commit c6e835a contained 3,679 files, about 1,341,907 source lines, and 60.9 MB. We found 23 CI workflow files and a tests directory, but no Dockerfile.
The test command did not complete within our 900-second cap. Its final lines showed multiple tests passing around analyzer sidecars, missing metadata, receiver calls, and Python AST dependency detection, but there was no final suite summary. We therefore cannot report a pass count or call the suite successful. Npm audit found 5 known high-severity vulnerabilities, with 0 critical, moderate, or low findings, so adopters should identify the affected packages before approving a shared deployment.
Five onboarding steps stand between download and a first research task
Packaged users go through 5 guided stages: environment checks, a data location, an agent runtime, a model provider, and optional notebooks. Open Science can manage Claude Code, OpenCode, Codex, or CodeBuddy runtimes without asking the user to install Node.js. A cloud provider or custom gateway needs a credential and network access. Claude and Codex users can instead connect an existing subscription through the documented login paths.
Building from source is less friendly. Development requires Node.js 22 and npm, while the install runs Prisma generation, patch checks, and Electron native dependency setup. Our 113-second install and 238-second build passed, yet the 2,220 MB dependency footprint is larger than many complete desktop applications. The repository provides platform packaging commands for macOS, Windows, and Linux. It provides no Dockerfile, which fits its desktop focus and complicates disposable review environments.
Reproducibility in v0.25.1 records evidence without exact replay
Open Science preserves immutable artifact bytes and available production evidence, but v0.25.1 does not promise deterministic reruns. Its release notes say environment inventory is not a solver lock, portable environment restoration remains open, and code reconstruction is generated by a language model. Open issue 2016 also requests a complete portable session package containing transcripts, intermediate outputs, provenance, and reviewer results. The current export surface does not satisfy that issue's requested package.
The permission story has a similar boundary. Scoped allow grants, encrypted credential storage, workspace containment, and notebook network rules exist, while user-configurable directory grants and automated credential rotation remain open. Windows requires a one-time administrator setup before notebook and compute traffic falls under the network sandbox. A lab with formal isolation requirements should test those boundaries on each of its 3 supported desktop operating systems before approving sensitive datasets.
September 2026 activity is high, and unfinished surfaces remain visible
GitHub recorded a push on September 6, 2026, with 3,734 stars and 47 combined issues and pull requests. Release v0.25.1 had arrived 3 days earlier with Windows kernel, export, preview, session, and provider fixes. Same-day pull requests covered storage recovery, credentials, session performance, and a proposed v0.26.0 bump. The pace shows active maintenance, though the combined open count should not be read as 47 defects.
Fresh bugs still touch workflows beyond the main Electron window. Issue 2119 reports that Remote Web cannot choose a Specialist ZIP because the button calls a desktop-only file dialog. Issue 2184 reports failed plan creation alongside unresolved artifact reconciliation. The useful project and provenance model remains intact. These reports argue for a scoped pilot with non-sensitive data, narrow approvals, and a separate record of the chosen model and environment. The 900-second test timeout should also fit your maintenance budget.