ScienceClaw: A Self-Hosted Research Assistant That Runs Its Agent Inside a Docker Sandbox
ScienceClaw is a personal research assistant built with LangChain DeepAgents and AIO Sandbox infrastructure, adopting a completely new architecture beyond OpenClaw. It offers stronger security, better transparency, and a more user-friendly experience.
At a glance
- What is it?
- ScienceClaw packages LangChain DeepAgents, an AIO Sandbox execution layer and roughly 1,900 scientific tools behind a Docker Compose file. The security boundary is the interesting part, and the licence and the tool count are the parts you should check before committing.
- Who is it for?
- Adopt ScienceClaw if you want a self-hosted research assistant whose code execution stays inside a container and whose intermediate steps you can inspect, and if you are willing to read the repository before trusting the tool count. Do not adopt it if you need a signed desktop build for macOS or Linux, if you require a permissively licensed dependency graph you can audit today, or if you cannot spare 8 GB of RAM.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 130 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem ScienceClaw Targets: Research Agents That Touch Your Machine
Most LLM research assistants share one uncomfortable property. The agent writes code and that code runs somewhere near your data. If the agent runs on your laptop, a generated script can read your SSH keys, your browser profile, or your environment variables. ScienceClaw's answer, per the README, is to put the whole thing in Docker containers and keep execution inside an isolated sandbox, with generated data landing in a local ./workspace directory rather than being uploaded elsewhere. The stated audience is researchers, developers and students who want to run literature and data workflows locally instead of handing prompts and datasets to a hosted service. The repository topics point at the same audience: pubmed, bioinformatics, drug-discovery, data-analysis. This is not a general chat wrapper. It is aimed at people who already run analysis pipelines and want an agent layered on top of them without giving that agent host access.
Architecture: DeepAgents Orchestration Over an AIO Sandbox
The stack named in the README has four moving parts. LangChain DeepAgents handles the agent loop and tool invocation. AIO Sandbox provides the execution isolation. A FastAPI backend sits in ScienceClaw/backend, a Vue frontend in ScienceClaw/frontend, and a separate scheduler in ScienceClaw/task-service, which suggests long-running or scheduled research jobs rather than purely interactive sessions. Tool and skill packages live in top-level Tools and Skills directories. The transparency claim rests on this layout: because the agent's tool calls are routed through a service you control, the README says each step from web search and crawling through reasoning to tool invocation and report generation is visible and traceable. That is a plausible design, not a guarantee. Traceability depends on how much of the reasoning loop the backend actually persists, and the README does not document a log format, a trace viewer, or a retention policy. Treat the transparency claim as an architectural direction to verify in the code, not as a finished feature.
Deployment: One Compose Command, Two Different Installers
The install path splits by platform. Windows users are pointed at a desktop installer, ScienceClaw-Desktop-Setup-0.0.4.tar.gz, hosted on Gitee, which the README says needs no Docker and no command line. macOS and Linux users go through Docker. Prerequisites are Docker and Docker Compose, with at least 8 GB of RAM recommended. The release path is a single command: docker compose -f docker-compose-release.yml up -d --pull always, which pulls pre-built images. Developers who need to modify code use docker compose up -d --build instead, and the README warns the first build downloads dependencies and takes longer. The UI then serves at http://localhost:5173. Default credentials are admin and admin123, and the README explicitly asks you to change the password after first login. Note what is missing from that sequence: no .env example, no model provider key configuration, no explanation of where the LLM endpoint is set. The README mentions free token allocations from SCNet and Zidong Taichu Cloud, so the hosted model path is clearly intended, but the self-hosted configuration surface is not documented in the material available here. Budget time for reading docker-compose-release.yml before you assume the one-command claim holds end to end.
The 1,900+ Tool Claim and What It Actually Contains
ScienceClaw's headline number is 1,900+ built-in scientific tools, delivered through something called ToolUniverse. The README lists domains rather than individual tools: target identification via OpenTargets, ADMET prediction, drug safety via FAERS, protein analysis via UniProt, PDB and AlphaFold, genomics via GWAS and GTEx, clinical trials, plus astronomy and other fields in a table that is truncated in the available material. Two things are worth saying plainly. First, a count of tools tells you about breadth of integration, not about reliability or depth of each wrapper. Second, many of the named sources are remote databases and web services, which means a large fraction of those tools are API clients that will need their own credentials, rate-limit handling and network access. That does not make the number false. It does mean the practical setup cost is higher than the single-command framing suggests, because the sandbox isolates execution but does not supply the upstream API keys. If you are evaluating this for a lab, the question to answer is how many of the 1,900 work without any external account.
Where ScienceClaw Is the Wrong Tool
Three limits stand out from the material. The licence field is empty in the repository metadata, while the README badge and a link point at an MIT LICENSE file. Those two signals disagree, and the discrepancy matters if you plan to redistribute the code or embed it in a commercial product. Until you open the LICENSE file yourself, treat the licensing as unresolved. Second, the sandbox model cuts both ways. An agent that cannot reach the host also cannot read your existing local datasets unless you place them in the mounted workspace, and it cannot use your host-installed scientific binaries. If your workflow depends on a licensed local toolchain, the isolation becomes friction rather than protection. Third, there is no release information retrieved for this repository, and the desktop installer is versioned v0.0.4 and distributed as a .tar.gz on Gitee. A tarball rather than a signed platform installer is a distribution detail worth noticing, particularly on macOS where unsigned applications face Gatekeeper friction. The README's own deployment guide is written in Chinese, which raises the reading cost for English-only teams.
How It Differs From a General Coding Agent
The obvious comparison is a general-purpose coding agent such as OpenClaw, which the README names directly as the architecture ScienceClaw moves beyond. The difference is scope and containment. A general coding agent is optimized for editing files in your project, and it typically runs with your user permissions in your working directory. ScienceClaw inverts that: the agent's execution environment is a container with a mounted workspace, and the surrounding system is specialized for scientific retrieval and analysis rather than repository editing. The trade-off is real. You lose the ability to have the agent refactor your codebase in place, and you gain a boundary between generated code and your host. If your task is literature synthesis, sequence lookup, or running a generated analysis script against a dataset you deliberately stage, the narrower design fits. If your task is modifying a live repository, it will feel like an obstacle course.
Maintenance, Upgrade Cost and the Licence Question
Upgrades are the least glamorous part and the README handles them in two lines: git pull in the existing checkout, then re-run the release compose command with --pull always. Because the release path uses pre-built images, you are not rebuilding Python wheels on every update, which keeps upgrade time low. The cost you do carry is the container footprint and the 8 GB RAM floor, plus whatever the scheduler service does in the background. There is no documented migration process for the workspace directory or for any database the backend uses, so a version jump that changes schema is an unquantified risk. On licensing, the repository metadata shows no licence value while the README badge and link indicate MIT. I am not giving legal advice here; the practical point is that a licence badge is not a licence file, and the file is what governs. Open LICENSE at the repository root before you make any distribution decision, and if it is absent, ask the maintainers rather than inferring from the badge.
Editorial conclusion
Adopt ScienceClaw if you want a self-hosted research assistant whose code execution stays inside a container and whose intermediate steps you can inspect, and if you are willing to read the repository before trusting the tool count. Do not adopt it if you need a signed desktop build for macOS or Linux, if you require a permissively licensed dependency graph you can audit today, or if you cannot spare 8 GB of RAM. Verify three things first: the actual contents of the LICENSE file, how many of the 1,900+ tools are thin wrappers around remote APIs that need their own credentials, and whether the admin/admin123 default survives your first login.
Community notes