open-science

---

News

• 2026-11-07 — 🧠 OpenCode 2, and more from every agent. The bundled runtime moves to OpenCode 2, with your OpenCode 1 history backed up first; a model’s reasoning shows in the thread; ACP agents bring their own slash commands, context usage and task list; DeepSeek Harness joins the catalog. Plus sharper CJK text in terminals and a window that keeps its size. (v0.7.2)
• 2026-10-29 — 🖥️ Terminals that stay, agents side by side. Terminals now run outside the app and survive updates, relaunches and crashes; Claude Code, Codex and pi run as conversations beside OpenCode, and a session moves between terminal and conversation in one click. Plus several accounts per agent, theme variants, new models on slow networks, and Chinese punctuation that goes in on the first press. (v0.7.1)
• 2026-10-26 — 🌐 The workbench from any browser, and agents that talk to each other. Splits, Screens and terminals now work over Remote Access, on a phone too, with name-and-password accounts; define your own Specialists with their own instructions, skills, connectors and model; and agents read and message each other’s conversations and terminals through osd. Plus queued messages while the agent works, and a no-root Linux install. (v0.7.0)
• 2026-10-04 — 🖱️ Computer Use, terminals and editors. The agent can now operate desktop apps like ImageJ, Origin and instrument software; panes hold terminals, files and a code editor, where Claude Code / Codex resume after a relaunch; plus find (⌘F), jump to any session or project (⌘J), and Linux ARM64 for DGX Spark. (v0.6.0)
• 2026-08-18 — 🖥️ Runs without a screen, and the terminal command comes with it. osd server starts the whole workbench — workspace, agent runtime, and the same web UI — on a machine with no display, and osd session send … --wait drives it from a script or another agent. osd ships inside the desktop installer and puts itself on your PATH on first launch; on a server the archive needs nothing installed. Models, keys and approvals are all configurable from the terminal (osd model, osd auth, osd approval).
• 2026-08-13 — 🔌 Speaks the Agent Client Protocol, both directions. Drive Codex, Gemini CLI, Claude Code, or any other ACP agent from inside this app — with its own models, history, and your MCP connectors — or drive Open Science itself from Zed, JetBrains, or Neovim. (v0.4.0)
• 2026-08-01 — 🗂️ Projects, memory, and full history. Group sessions into named projects (import an existing repo in place, no copying), give the agent persistent global and project memory, and reach every past conversation through a searchable history with archive, restore, and export. (v0.3.1)
• 2026-07-24 — 🪟 Split-pane tiling. Tile sessions side by side, drag panes to re-dock them, keep several independent Screens, and run a different model in each pane. (v0.3.0)
• 2026-07-21 — 🌐 Access from anywhere — even your phone. A token-authenticated gateway serves the real desktop UI to a CLI, a browser on your LAN, or your phone (loopback by default; LAN is opt-in). Start a run at your desk and read the finished figure and report on your phone. (v0.2.3)
• 2026-07-21 — 🧭 Browser control. The agent can drive your own Chrome — profile and logins intact — to read the live web the way you do, or an isolated private browser on demand. (v0.2.3)
• 2026-07-09 — 🎉 #1 on ResearchClawBench. Open Science Desktop ranks #1 by scored-task average on ResearchClawBench, an end-to-end benchmark for autonomous scientific research agents (Pass@1 leaderboard).

---

Contents

• ✨ What it does
• 🎬 See it in action
• 🧪 Current capabilities
• 🔌 Skills and connectors
• 📦 Install
• 🖥️ Headless & CLI (osd)
• 🚀 Build from source
• 🔒 Safety and privacy
• 🗂️ Repository layout
• 📌 Status
• 🤝 Contributing
• 📖 Citation
• ⚖️ License

What it does

Runs the whole research loop — from a broad direction to a finished paper: exploration, literature survey, hypothesis, experiment code, analysis, figures, and write-up, in one continuous, auditable session.

• Autonomous research agents — the bundled ai4s-agent chains specialist skills end to end (explore → survey → experiment → write), and each stage drops a real, inspectable artifact into your workspace, not just a chat reply.
• Everything traces back — figures, tables, reports, notebooks, and run outputs link to the exact code, inputs, environment, model output, and conversation that produced them.
• Local-first and yours — sessions, data, provenance, notebooks, and run records live in local folders on your machine. Nothing leaves by default.
• Model-agnostic runtime — the UI talks through packages/sdk to a bundled, pinned OpenCode sidecar. Bring your own model; providers, skills, and MCP servers stay pluggable.
• Reproducible by construction — local, SSH/Slurm, Modal, and notebook-batch runs are captured as reproducible run records, not loose terminal scrollback.
• Reach it from anywhere — a built-in, token-authenticated gateway serves the real desktop UI to a browser on your LAN or phone (or, with a tunnel, from anywhere) — kick off a run at your desk and check on it from your phone over lunch. Off by default; loopback-only until you opt in, and API keys never leave the machine.
• Drives your own browser — the agent can control your real Chrome, with your profile and logins intact, to read the live web the way you do — or an isolated private browser when you’d rather it not.
• Plan before it acts — /plan lays out an execution plan before touching a file, and /goal fixes the objective, constraints, and acceptance criteria the agent then works toward.
• Built for long projects — named projects group their sessions, two layers of persistent memory (global and per-project) carry what matters between them, and a long conversation compacts itself as it approaches the model’s context window.
• Work several threads at once — tile panes side by side, keep independent Screens, and give each pane its own model.
• Extensible — agent skills, MCP servers and one-click science connectors, / commands, ! shell mode, and a model-agnostic SDK.

See it in action

One prompt -> a publication-grade figure, and every point traces to the exact code and inputs that made it. No black boxes: open any artifact to see its generating script, its data files, and the conversation that produced it.

Literature -> a verifiable report. Fan the search out across sources, draft a manuscript rendered as a PDF, and gate it on a citation review — DOIs resolved, unsourced numbers and figure/code inconsistencies flagged — before anything ships.

Drives your own Chrome. The agent reads the live web through your real browser profile — logins and all — then turns what it finds into a figure and a sortable CSV.

Research from anywhere — even your phone. A built-in authenticated gateway serves the real desktop UI to a browser on your LAN (or a tunnel), so you can kick off a run at your desk and read the finished figure and report on your phone.

New session

A finished analysis

A reproduced benchmark

More screenshots

Current capabilities

The research loop, as skills. One meta-skill runs the full pipeline; each stage is a self-contained skill that produces a real, gradeable artifact — runnable on any model OpenCode supports:

Skill	Role	Primary output
ai4s-agent	Runs the four skills below, in order	The full research package
research-explorer	Turn a broad direction into concrete topics	research_exploration.md, topic_matrix.md, literature_pre_survey.md
literature-survey	Write a literature survey	6–20 pp PDF, 60+ real citations, LaTeX source, taxonomy figures
experiment-suite	Build an experiment package	Design doc, runnable code, results.json with provenance, figures, report
paper-writer	Write a research paper	8–14 pp PDF, 200+ citations, 4–8 figures, tables
mindmap-render	Render a mindmap	Image generated from a topic_matrix.md
integrity-auditor	Audit a paper’s integrity	Image / numerical / logical findings, 4-level evidence grading, audit_report.md

These ship in the ai4s-skills pack alongside first-party review skills and the office/document skills below.

Platform

Area	Current state
Desktop shell	Tauri 2 + React + TypeScript + Vite, with macOS, Windows, and Linux desktop builds.
Runtime	Bundled OpenCode sidecar, auto-started by the app, isolated from the user’s own OpenCode config/data.
Projects	Named project workspaces that group their sessions; import an existing folder in place (never copied) or adopt one already inside the workspace; move an existing session into a project.
Sessions	Multi-session chat/history, dated workspace folders, searchable history with archive/restore/export, @ file and # conversation references, / commands, and ! shell mode.
Layout	N-ary split-pane tiling with drag-to-dock, independent Screens, per-pane model and reasoning effort, and cross-screen pane drag.
Agent modes	/plan for plan-then-execute, /goal for objective and acceptance criteria, live subagent status in its own panel, and Stop that reflects the runtime’s real server state.
Memory	Global and per-project memory layers, switchable, plus automatic context compaction as a conversation approaches the model’s window.
Remote compute	Register machines from your ~/.ssh/config, probe them, and submit, track, or cancel jobs from the app.
Appearance	Light, Warm, and Dark themes with per-theme accents, and UI zoom.
Files	Global and per-session file browsing, context menu actions, external open/reveal, copy path, and local preview server.
Headless & CLI	osd server runs the workbench with no window — same workspace, same runtime, same web UI, served from one self-contained directory — and osd drives it (or a running desktop app) from a terminal: sessions, projects, runs, files, approvals, --wait, --json.
Remote access	Token-authenticated gateway that serves the real UI to a CLI, a LAN web browser, or your phone (loopback by default, LAN opt-in); read-only vs full access modes; copy a link with the token embedded to connect in one tap. API keys never cross the wire.
Editor interop (ACP)	Speaks the Agent Client Protocol in both directions: run any ACP agent (Codex, Gemini CLI, Claude Code, …) as the runtime behind the ordinary UI, with its own model and reasoning selectors, history replay, and this app’s MCP connectors; or let an external editor (Zed, JetBrains, Neovim, …) drive Open Science, reusing the gateway token.
Browser control	The agent drives your own Chrome — profile and login state preserved — reading pages through the accessibility tree, or an isolated/private browser on demand.
Computer use	The agent reads and drives apps on your own screen through the platform’s accessibility API — native research software included — acting on named elements rather than guessing at pixels, and reporting whether each action could actually be verified. On macOS the Accessibility permission is held by a separate helper, not by the whole app; Screen Recording, which only optional screenshots need, is granted to Open Science itself because macOS attributes screen capture to the app that started the request.
Notebooks	Real .ipynb files, Python and R notebook creation, local kernel execution, managed Jupyter environment via bundled uv, and an Open JupyterLab action.
Runs	Append-only run logs, global SQLite run index, search/facets/pagination, local/remote surfaces, output links, logs, and reproduce prompts.
Provenance	.openscience/provenance.jsonl tracks file versions and links produced artifacts back to the run or edit that created them.
Review	Traceability, statistics-integrity, domain-check, large-file, publication-figure, remote-compute, and Modal run skills are bundled as first-party skills.
Viewers	PDF, image, video, HTML, Markdown, code, CSV/TSV tables with charts, DOCX, XLSX, PPTX, molecules, 3D meshes, genome tracks, FITS, DOS/DOSCAR, EIGENVAL bands, qcode, anomaly maps, and phase files.
Models	OpenCode provider catalog, OAuth/API-key provider flows, custom OpenAI-compatible endpoints, and local/provider-specific options supported by OpenCode.
Interface languages	English, Simplified Chinese, Japanese, Spanish, German, French, and Korean. Portuguese (Brazil) and Arabic are registered but not selectable yet.

Skills and connectors

Bundled skills are fetched for builds and releases instead of being committed into git history:

• ai4s-skills pack from ai4s-research/ai4s-skills.
• Office/document skills from the Apache-2.0 anthropics/skills repository: docx, pdf, pptx, and xlsx.
• First-party core skills in runtime/skills/core/: traceability-review, stats-integrity, domain-check, large-file, publication-figures, remote-compute, and modal-run.

One-click science MCP connectors currently include:

• Literature search: arXiv, PubMed, Crossref, Semantic Scholar, bioRxiv/medRxiv.
• Biomedical databases: PubMed, ClinicalTrials.gov, MyVariant/ClinVar.
• Materials Project.
• FRED economic data.
• Space weather.
• Open-Meteo weather and climate.
• USGS water data.

You can also add any local or remote MCP server from Settings. See docs/CONNECT_YOUR_TOOLS.md.

For a neutral positioning note, see Open Science Desktop vs OpenScience.

Install

Download the latest installer from the Releases page.

• macOS: .dmg / .app, Apple Silicon and Intel, macOS 13 Ventura or later.
• Windows: NSIS .exe, Windows 10/11 x64 — installs per user, no admin needed. A .msi is also published for IT-managed deployment; pick one format and stay on it.
• Linux: .deb and .rpm on x86_64 Linux.

The macOS packages are Developer ID signed, notarized, and stapled, so they open normally — no xattr workaround needed. Windows and Linux builds are not signed yet.

Windows: if SmartScreen appears, choose More info -> Run anyway.

Linux:

sudo apt install ./Open.Science_*.deb
# or
sudo rpm -i Open.Science-*.rpm

No root? This installs everything under your home directory — osd by default, the desktop app with --desktop (which needs WebKitGTK 4.1 already on the system). --uninstall removes it again.

curl -fsSL https://raw.githubusercontent.com/ai4s-research/open-science/master/scripts/install.sh | sh
curl -fsSL https://raw.githubusercontent.com/ai4s-research/open-science/master/scripts/install.sh | sh -s -- --desktop

Headless & CLI (osd)

A research machine usually has no screen. osd is the same workbench without one: the same workspace layout, the same agent runtime, the same projects, and the same web UI — served over HTTP instead of drawn in a window.

On a server, take the archive. osd-<version>-<target> from Releases unpacks and runs with nothing installed — verified on a bare Ubuntu container with no packages added at all.

# Configure the machine (works before any server is running)
./osd auth set anthropic --key sk-…       # stays on this machine, never on the wire
./osd model set anthropic/claude-opus-4-5 # the default for every turn
./osd server --lan                        # prints its URL and access token

Keys never have to touch a file: the agent runtime inherits this process’s environment, so ANTHROPIC_API_KEY=sk-… ./osd server needs no auth set at all. A self-hosted or proxied endpoint goes in the same command (--base-url https://my-gateway.internal/v1), and osd auth ls prints provider names only — no key is ever printed by anything. Changing a key needs a restart; the CLI says so rather than leaving you to wonder.

Open the printed URL and you get the real desktop UI in a browser, phone included. Or drive it from a terminal — on the same machine, over SSH, or from your laptop:

osd project new "Reef survey"
id=$(osd session new --project "Reef survey")
osd session send "$id" "Fit the 2015–2024 bleaching trend and write report.md" \
    --model anthropic/claude-sonnet-4-5 --wait
osd fs ls figures/
osd fs get report.md --output ./report.md

On Windows the same commands work in PowerShell; only the shell’s own syntax differs:

$id = osd session new --project "Reef survey"
osd session send $id "Fit the 2015-2024 bleaching trend and write report.md" --wait

On your own machine it is already installed. The desktop installer carries osd, and the app puts it on your PATH the first time it starts, so a new terminal has the command with nothing to set up. It writes one small wrapper (~/.local/bin/osd, or ~/bin when a terminal already searches that) — never a symlink, because osd finds its runtime next to its real executable. If that folder is not on PATH, the app adds it to your login profile and Settings → Remote Access says which file it touched. Nothing else on your shell is changed.

--wait returns when the turn is finished, not when it was accepted, and fails loudly if it produced no reply. --json prints the API’s own response for scripts.

Concurrency and per-project setup

Parallel work does not need a second server, or a second workspace: one osd server already runs many sessions at once. The gateway is thread-per-connection and nothing on the session path holds a global lock — what keeps one session’s work out of another’s is the folder each one is pinned to. osd session new --project NAME runs a session in a per-project folder of the workspace (created with osd project new NAME), and osd session new --directory DIR pins one to any other folder.

Per-project MCP follows the folder too: an MCP server declared in <folder>/.opencode/opencode.json applies only to sessions working in that folder, and every session shares the same sidecar. One caching rule makes the ordering matter: a folder’s opencode configuration is read once, the first time the sidecar uses that folder, and cached from then on. Write that configuration before any session is pointed at the folder: osd session new --project NAME (or --directory DIR) already reads and caches it, before a single turn has run, so “before the first turn” is already too late. Changing it afterwards takes effect only after a server restart, and until then the session runs, reports success, and used the previous configuration.

None of this needs a second installation of the workbench.

Isolated state directories (–state-dir)

osd server --state-dir DIR — or OSD_STATE_DIR=DIR — keeps everything one instance writes (session database, sidecar config, workspace record, logs) under DIR instead of the platform data directory. Nothing else changes: the default workspace still resolves to your real Documents folder, and the desktop app is unaffected, because it never goes through the headless override.

This is NOT a way to get more concurrency — one server already runs many sessions at once (above). It is for genuinely separate installations on one machine: an unattended shard next to the desktop app, a benchmark cluster.

Credentials stay per instance and are never copied: a fresh DIR has none, so the first server started there prints a note and the one-liner that adds one — OSD_STATE_DIR=DIR osd auth set <provider> --key … — or you export the provider’s own variable (ANTHROPIC_API_KEY=…) before starting and the sidecar inherits it.

Which model, and who approves what

osd model shows the default, osd model ls lists what the runtime can actually serve (the providers this machine has credentials for, current one marked), and osd model set <provider/model> changes it — over the gateway, so it works against a remote server too. Any single turn can override it with osd session send --model … --agent … --effort ….

Approvals still apply: the agent asks before running commands, deleting files, installing dependencies or reaching the network. Without a window, --wait names what is waiting and offers both answers — osd permission ls / osd permission allow <id> in the terminal, or the gateway URL it prints, which carries the token so a browser on your laptop or phone can approve it.

For a machine with nobody watching, opt out explicitly:

osd approval            # what has to be asked today
osd approval set full   # never ask — commands, deletions, installs, network

full is a deliberate choice, not a default: the agent stays confined to the workspace, but nothing pauses for you. osd approval set approve puts every rule back. osd approval set full rewrites the runtime’s own config on this machine, so it has to run on the machine itself — over SSH, not through --gateway: the gateway deliberately refuses config writes, and says so rather than silently doing nothing.

As a service

osd server is an ordinary foreground process, so systemd runs it as-is. This unit was run end to end on Ubuntu — enable, restart, crash, stop:

# /etc/systemd/system/osd.service
[Unit]
Description=Open Science Desktop (headless)
After=network-online.target

[Service]
Type=simple
User=ubuntu
Environment=HOME=/home/ubuntu
ExecStart=/opt/osd/osd server --port 4788
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now osd and the printed URL and token land in journalctl -u osd. A unit is also the tidiest way to run it: systemd stops the whole cgroup, so the agent runtime never survives the server, however it dies.

With no --gateway given, osd talks to a gateway already running on the same machine — including the desktop app’s — so with the app open, osd session ls just works. Otherwise point it anywhere with osd login --gateway <url> --token <token>.

What is not there without a desktop: local Jupyter kernels, native file dialogs, and the OS file manager — the web UI hides those rather than offering controls that would fail. Two more are worth knowing: provenance and run records are written by the desktop client, so a headless server keeps the workspace’s file history through git snapshots but does not append to provenance.jsonl or the run index.

Build from source

Prerequisites:

• Node.js >= 20
• pnpm 9
• Rust toolchain
• macOS, Windows, or Linux system dependencies required by Tauri

git clone https://github.com/ai4s-research/open-science
cd open-science
pnpm install

# Fetch pinned sidecars and bundled skills. These are git-ignored.
bash scripts/dev/fetch-opencode.sh
bash scripts/dev/fetch-uv.sh
bash scripts/dev/fetch-skills.sh

# The osd terminal client is bundled too — it is ours, so it is built, not fetched.
bash scripts/dev/build-osd-sidecar.sh $(rustc -vV | sed -n 's/host: //p')

# Run in development or build installers.
pnpm --filter @ai4s/desktop tauri dev
pnpm --filter @ai4s/desktop tauri build

Useful checks:

pnpm test
pnpm typecheck
pnpm lint

Safety and privacy

• Workspace files, raw data, session history, provenance, notebooks, and run records stay local by default.
• Command execution, file deletion, dependency installation, and remote connections are human-approved flows in the desktop app.
• Provider credentials are written to app-private runtime config, not to the workspace, provenance, git, exports, or global OpenCode config.
• Settings includes a plain-language data-flow view explaining what can be sent to the selected model provider.

Repository layout

Path	Purpose
apps/desktop/	Tauri + React desktop app.
packages/sdk/	OpenCodeClient; keeps the UI from calling OpenCode directly.
packages/shared/	Shared domain types and chart palette.
packages/ui/	Shared UI package.
runtime/skills/core/	First-party scientific skills.
runtime/skills/external/	Build-fetched external skills.
runtime/harness/	Runtime harness knowledge and operator context.
runtime/mcp/	MCP runtime notes/configuration.
examples/	Built-in example workspaces.
crates/osd-core/	The server core — workspace, sidecar, gateway. No Tauri, so it runs headless.
crates/osd-cli/	osd: the headless server and its client.
scripts/dev/	Sidecar, uv, skill fetchers, and focused regression probes.
docs/	Product, technical, operator, connector, and research notes.

Status

The project is a working desktop MVP in active development. The most reliable current implementation log is PROGRESS.md. Product and architecture notes live in docs/PRD.md and docs/TECHNICAL_DESIGN.md, but those documents include target design as well as historical status notes.

Near-term work is focused on Windows code signing, auto-update, broader Windows/Linux verification, richer connector hardening, and continued reproducibility review. macOS releases are already signed and notarized.

Contributing

Issues and PRs are welcome. Keep changes minimal and verifiable, follow AGENTS.md, and run the checks before opening a PR. For discussion, join the Open Science Discord or the linux.do community.

Citation

If you use Open Science Desktop in your research, please cite it:

@software{open_science_desktop,
  author  = {{The Open Science Desktop Contributors}},
  title   = {Open Science Desktop: a local-first, model-agnostic AI research workbench},
  year    = {2026},
  version = {0.7.2},
  doi     = {10.5281/zenodo.24034527},
  url     = {https://github.com/ai4s-research/open-science},
  license = {MIT}
}

GitHub’s “Cite this repository” button (top of the repo page, generated from CITATION.cff) provides the same reference in APA and BibTeX.

License

MIT. Bundled third-party skills and connectors keep their own licenses.

Computer use is a port of the design and native providers from Orca (MIT) — an accessibility-tree-first approach, with an explicit verified/unverified result on every action, that is simply the right way to build this. Our thanks to that team for doing it well and giving it away.

Open Science Desktop is beta research tooling. Treat outputs as drafts: verify numbers, citations, code, and conclusions before publication or decision-making.