Open Science Desktop: a local-first Tauri workbench for agent-driven research

The gap Open Science Desktop is aimed at

Most agent interfaces for scientific work end at a chat transcript. You ask for an analysis, you get code in a message, and the connection between that code, the data it read, and the figure it produced survives only as long as the conversation does. Open Science Desktop is built against that gap. The README describes a workbench that runs "exploration, literature survey, hypothesis, experiment code, analysis, figures, and write-up, in one continuous, auditable session", with each stage dropping "a real, inspectable artifact into your workspace, not just a chat reply". The intended user is a researcher or research engineer who already keeps code, data, and notebooks in local directories and wants an agent to operate on those directories rather than on an uploaded copy. Three properties define the target: sessions, provenance, and run records stay in local folders; the model provider is swappable; and results link back to the code, inputs, environment, model output, and conversation that produced them. That last claim is the one worth holding the project to, because it is the difference between a chat client and a research tool.

How the agent loop and the runtime are assembled

The architecture visible in the README is a Tauri 2 shell with a React front end, and the UI does not talk to a model directly. It talks "through packages/sdk to a bundled, pinned OpenCode sidecar". Pinning the runtime is a deliberate choice: it means the agent behaviour you test against is the agent behaviour you ship, at the cost of moving the runtime upgrade onto the project's release cadence rather than yours. On top of that sits the bundled `ai4s-agent`, which chains specialist skills through four named stages (explore, survey, experiment, write). Connectors come in two shapes: MCP servers, and agent skills, which the README groups under one heading and describes as extensible. The application also speaks the Agent Client Protocol in both directions, according to the 2026-08-13 release note: it can drive Codex, Gemini CLI, or Claude Code from inside the app, and it can itself be driven from Zed, JetBrains, or Neovim. That bidirectional ACP support is the most interesting structural decision here, because it means the workbench is not trying to be the only place your agent runs. Two control primitives sit above the loop: `/plan` lays out an execution plan before touching a file, and `/goal` fixes the objective, constraints, and acceptance criteria. Both are prompt-level conventions rather than enforced sandboxes, so their value depends on the model honouring them.

Install paths and the osd command surface

The README lists a desktop installer for macOS, Windows, and Linux, plus a source build under a "Build from source" heading. The more distinctive path is headless. The 2026-08-18 note states that `osd server` starts the workspace, the agent runtime, and the same web UI on a machine with no display, and that `osd session send ... --wait` drives it from a script or another agent. The `osd` binary ships inside the desktop installer and puts itself on PATH on first launch; on a server, the note says the archive needs nothing installed. Configuration is exposed on the same command surface: `osd model`, `osd auth`, and `osd approval` cover models, keys, and approvals from a terminal. For anyone running this on a shared cluster login node, that trio is the part to read first, because an approval policy set interactively on a laptop will not be the policy in effect on a headless host. The gateway is a separate concern: it is token-authenticated, serves the real desktop UI to a browser on your LAN or phone, defaults to loopback, and requires an explicit opt-in for LAN exposure. The README states API keys never leave the machine, which is consistent with a loopback-default gateway but is a claim about the gateway, not about the model providers you configure.

Run records across local, SSH/Slurm, Modal, and notebook-batch

The reproducibility story is the project's strongest concrete claim. Runs on local machines, SSH or Slurm clusters, Modal, and notebook batches are captured as "reproducible run records, not loose terminal scrollback". The distinction matters. Terminal scrollback is unstructured text that you cannot re-execute or diff; a run record implies a stored structure with the command, environment, and outputs attached. What the README does not specify is the record format, where the records are written, or how they are replayed. Those are the questions to answer before you build a lab workflow on top of this, and they are answerable from the repository rather than from the README. The same gap applies to provenance: the README says figures, tables, reports, notebooks, and run outputs link to the exact code, inputs, environment, model output, and conversation, but it does not describe the linking mechanism or its granularity. A link that records a file hash is a different guarantee from a link that records a session identifier. Treat the claim as a direction the project has committed to, not as a verified property.

Where the workbench model breaks down

Three limitations follow from the design as described. First, the licence. The repository metadata reports NOASSERTION even though the README carries an MIT badge and a DOI. Those two signals disagree, and the repository metadata is the one a compliance tool will read. Anyone adopting this inside an institution needs to open the LICENSE file directly rather than trusting the badge. Second, the extension surface is underdescribed. The README says the project is extensible through agent skills and MCP servers and mentions "one-click" configuration, but the text is truncated at that point, so the skill format, the manifest schema, and the versioning guarantees are not visible in the supplied material. If you plan to write your own skills, budget time to read the source. Third, the interface is broad by design: a desktop shell, a headless server, a LAN gateway, an ACP bridge in both directions, browser control, split panes, and two memory layers. Each of those is a surface that can break independently. The project is also pre-1.0, with the most recent release listed as v0.5.2 on 2026-09-08 and a rapid cadence across v0.5.0 through v0.5.2 in under three weeks. That cadence is a maintenance cost, not a maturity signal.

How it differs from JupyterLab with an AI extension

The closest familiar alternative is JupyterLab plus an assistant extension, and the difference is where the agent sits. In a notebook-centric setup, the notebook is the unit of work and the agent is a helper inside a cell context. Here the session is the unit of work, and notebooks are one artifact type among figures, tables, reports, and run records. That inversion has consequences. A notebook-centric stack gives you a mature execution model, a large extension ecosystem, and output documents that anyone can open without your tool. Open Science Desktop gives you a session history with archive, restore, and export, two layers of persistent memory (global and per-project), and run records that span local, SSH/Slurm, Modal, and notebook-batch execution under one record format. If your work is one long analysis in one notebook, the notebook stack is the better fit and the agent is a convenience. If your work is a sequence of stages across several machines with a write-up at the end, the session model is the reason to consider this project. The trade is portability: a notebook is a file other people can run, while a session is a record inside an application.

Upgrade cost, licence risk, and what to check before adopting

The release history shows v0.5.0, v0.5.1, and v0.5.2 within roughly three weeks, and the news entries document feature additions at a similar pace: ACP support in v0.4.0, projects and memory in v0.3.1, split-pane tiling in v0.3.0, gateway and browser control in v0.2.3. The README does not describe a migration policy, a deprecation window, or a stable plugin API, so an upgrade from v0.5.x to a later minor version should be treated as a change you test rather than a change you apply. Because the OpenCode runtime is pinned and bundled, runtime upgrades arrive with application upgrades, which reduces one class of drift and concentrates another. On licensing, the README shows an MIT badge and cites a Zenodo DOI, while the repository metadata says NOASSERTION. Do not resolve that from the badge. Read LICENSE, and if the terms matter to your institution, get them confirmed rather than inferred. The concrete first step is to clone the repository, read LICENSE, and inspect packages/sdk to see what the UI actually calls, since that package is named in the README as the boundary between the interface and the runtime.

Editorial conclusion

Adopt Open Science Desktop if your research workflow already lives in local folders and you want agent runs recorded as inspectable artifacts rather than chat transcripts, and if you are willing to read the repository's LICENSE file and the Tauri build path before committing. Do not adopt it if you need a stable plugin API, a published package-level changelog, or a licence you can verify from the repository metadata alone, since the repository reports NOASSERTION. Verify two things first: the actual terms in LICENSE, and whether packages/sdk exposes the extension points your own tooling would need.

Official sources

1. ai4s-research/open-science on GitHub
2. Issues
3. Project website
4. README
5. Releases