ai4s-research/open-science

• 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).

• ✨ 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

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.

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

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:

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

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.

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

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.

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.

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.

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.

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.

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

• 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.

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.

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.

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.6.0},
  doi     = {10.5281/zenodo.23138229},
  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.

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.