BioClaw puts BLAST in a group chat, and SSH from the same chat box

A bioinformatics assistant you message like a colleague

BioClaw puts a computational biology toolkit behind a chat interface. You mention the assistant in a WhatsApp group, describe the analysis in ordinary language, and the results come back into the thread as images, plots and structured reports.

The capability list is the substance of the project. Sequence analysis runs BLAST against NCBI databases, aligns reads with BWA or minimap2 and calls variants. Quality control generates FastQC reports with automated interpretation rather than leaving you to read the raw output. Structural biology fetches 3D protein structures from the Protein Data Bank and renders them. Data visualisation turns CSV files into volcano plots, heatmaps and expression figures. Literature search queries PubMed and returns structured summaries.

One capability is worth separating out, because it is not a command-line tool at all. Image-based wet-lab interpretation analyses photographs of gels and blots, taken with a camera or uploaded into the chat, for things like SDS-PAGE lane quality and whether the target band is where it should be. That is a judgement task on an image rather than a pipeline invocation.

The framing of the problem is fragmentation: researchers moving between command-line tools, visualisation software, databases and literature search engines across different machines. The assistant's value is the removal of that switching, not any single analysis.

Six messaging integrations, and one of them is a release candidate

The README leads with WhatsApp, but the dependency list shows a wider surface than the headline suggests. There is an SDK for Lark, one for Slack, one for WeCom, one for Discord, a WeChat agent SDK, and WhatsApp itself through a community library.

That last one is the one to look at. The WhatsApp client is an unofficial library pinned to a release candidate line, which for a project whose primary documented channel is WhatsApp is an unusual place to be. Unofficial clients depend on protocol behaviour that the operator can change without notice, and an RC version means the API your integration depends on may still move under you.

The rest of the dependency set is sensible for what the project does. A 3D molecule viewer handles the protein structure rendering, a SQLite driver stores state, a cron parser handles scheduled work, HTML sanitising and Markdown rendering handle agent output that will be displayed in a chat client, structured logging is there, and a schema validator guards the boundaries. Tests run on Vitest with TypeScript compiling through tsc.

That is this project in one line: a multi-channel product where WhatsApp is the front door, and channel-specific breakage is the operational problem you will hit first.

SSH from the chat box is the feature to think hardest about

Among the recent additions is host-side SSH executed straight from the chat box. You type an SSH alias, optionally followed by a command, and the assistant runs it from the host using the aliases you have already configured.

That is a genuinely useful feature for a lab, because the analysis host is often not the laptop and SSH aliases are how everyone already reaches it. It is also the most consequential line in the changelog, because it turns a chat message into a command executed on a machine that also holds your credentials.

The project is not silent about the surrounding risk. The quick start points anyone uncomfortable with Docker, environment files, workspaces, allowlists or mounts to a beginner guide first, which implies there are controls: allowlists and mount configuration are named as concepts the setup handles. What the visible documentation does not state is how those controls relate to the SSH path specifically, or who in a group chat is permitted to trigger it.

That is the question to answer before inviting a lab full of people into the group. An assistant that can run BLAST and shell out is already powerful; one that can also open an SSH session to any host you have aliased is a remote execution surface, and the difference between those two things is an authorisation decision that should not be implicit.

Skills arrive from a hub repository before they land here

BioClaw sits on two upstream projects. The architecture comes from NanoClaw, and the bioinformatics tooling and skills come from a project called STELLA, with the agent runtime provided by the Claude Agent SDK.

Capabilities are packaged as skills, which is what makes the toolkit extensible. A new skill can be written directly inside BioClaw or in a separate skills hub repository, and the README describes the hub as a staging space for early iteration and testing. Skills that prove practical and stable are promoted into the main repository later, and users pick up promoted skills by pulling the repository.

That two-stage model is a reasonable answer to a real problem, which is that a skill that works for one dataset in one lab is not yet a skill worth shipping to everyone. It also means the feature set you get depends on when you last pulled, and there is no version pinning described for skills.

Inside the chat there is visibility and preference control: a command lists the installed skill modules and lets you mark preferred ones for the current thread or agent, which matters once several threads are doing different kinds of work.

Four provider options, two of which need no key

The example environment file is more interesting than a single API key, because it documents four ways to authenticate and two of them borrow a login you already have.

Anthropic is the default and takes an API key. OpenRouter is the second option, taking its own key plus a base URL and a model identifier, and the file helpfully lists popular model identifiers from several vendors behind that one endpoint.

The third option reuses an existing Codex CLI login. You select the provider, BioClaw reads the credentials file the Codex CLI already wrote and uses the installed CLI, and no API key is needed at all. The fourth does the same with the Gemini CLI, either through the OAuth credentials that its own login command writes or with a direct key, and it requires the Gemini CLI to be on the path.

Fast switching between these is handled by presets stored outside the repository, in a configuration file under the user's config directory, described as being in the style of existing model-switching tools.

The reason this matters for a lab is provenance. Two of these options bill through a personal subscription rather than an organisation account, which changes who pays and who can see the usage.

A dozen slash commands, and a per-thread working directory

The recent work is mostly about control from inside the chat rather than new biology, and it reads as a project hardening itself for group use.

There is a control layer you can drive from the thread itself, with commands for status, diagnostics, listing and switching threads, starting a new one, renaming, archiving, moving between workspaces, choosing a provider and choosing a model.

Then there is the structural fix. A per-thread working directory means each thread can remember its own default folder inside the workspace, so two conversations can work in different subdirectories without colliding. Paired with multiple web chats that each keep their own memory, it means one thread can stay on literature search while another handles quality control.

Reusable shortcuts complete the picture. Saving a common prompt as a short command means a repeated lab routine is a short invocation rather than a retyped paragraph, which is the difference between a tool people use daily and one they abandon after a week.

One small nicety worth copying: a health-check script sends a tiny test request with your current environment so you can find out whether a key works before debugging the rest of the application.

One setup script, Docker Desktop, and a version behind the tag

Installation is a clone and a script, with separate paths per platform:

git clone https://github.com/Runchuan-BU/BioClaw.git
cd BioClaw
bash scripts/setup.sh

git clone https://github.com/Runchuan-BU/BioClaw.git
cd BioClaw
powershell -ExecutionPolicy Bypass -File scripts\setup.ps1

The script checks prerequisites, installs dependencies and builds the Docker image. You need Node.js 20 or newer, Docker Desktop, and on Windows PowerShell 5.1 or later. The repository carries a container directory, a launchd directory for macOS service management, configuration examples, an example task directory and a mount allowlist example.

Three housekeeping details. The package manifest reads version 0.1.0 while the newest release is v0.1.1, so the manifest trails the tag. That release is dated 2026-04-18 and the previous one a Windows x64 build from 2026-04-17, while the last push to the repository was on 2026-08-24, so roughly four months of work sit after the last release. And the repository declares no recognised licence identifier even though a licence file is present at the root, which is worth resolving before anyone builds on it.

The project also points to a homepage, a bioRxiv preprint and an arXiv entry, plus a directory on a community site for the project.

Editorial conclusion

BioClaw suits a lab that wants its members to run standard analyses from a chat thread without anyone opening a terminal, and that already keeps its tools and reference data on a host the assistant can reach. It does not suit a group where untrusted members can message the assistant on a machine that also holds your SSH aliases, because the SSH feature turns a chat message into a host command. Verify first which channel you actually need and what it implies for the unofficial WhatsApp dependency, how the allowlist and mount configuration constrain what the agent can touch, and which provider authentication works in your organisation before you invite anyone else into the group.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Runchuan-BU/BioClaw on GitHub