InnoClaw: a self-hosted research workspace that grounds an agent in your own folders

The problem InnoClaw targets: research material scattered across folders, tools and clusters

Most research groups already own their data. It sits in a lab server directory, a shared mount, or a cluster home folder. What they do not own is a single place to ask questions about it. The README frames the gap directly: instead of juggling separate tools for literature, notes, code and automation, you open a folder, sync it, and work. InnoClaw's stated audience is narrow and specific: researchers who read papers and run experiments, ML and AI engineers who need a workspace for code and data plus agent-assisted execution on remote clusters, lab teams that want a shared self-hosted hub rather than scattered SaaS tools, and self-hosters who want control over data, models and infrastructure. The last group matters most, because the design assumes you are willing to run Node.js, a SQLite database and a model provider yourself. If you are not, the rest of the product is irrelevant to you.

How the workspace mechanism actually works: folders, a SQLite schema, and citations over synced files

The unit of work is a server-side folder exposed as a persistent workspace. You declare where those folders live with WORKSPACE_ROOTS in .env.local, pointing at one or more absolute paths. The README is explicit that those directories must already exist before startup; InnoClaw does not create them for you. After configuration, the flow shown in the quick start is: open a workspace, click Sync, then chat. The sync step is what makes answers grounded, because the chat is described as RAG-backed with citations over your files rather than over a general corpus. State lives in SQLite. Running npx drizzle-kit migrate creates or upgrades the schema at ./data/innoclaw.db, which is why the quick start includes mkdir -p ./data before the migration. That database is the persistence layer for workspaces and, per the v0.3.0 release notes, for persistent agents. Two operational details follow from this. First, the database is a file, so backup and restore are file operations, not service operations. Second, because SQLite relies on local file locking, the README advises setting DATABASE_URL to a local disk path even when the repository itself sits on NFS or CIFS. The project works around one part of that problem: it now disables Next's dist-dir lock automatically so npm run dev can start on such mounts, and NEXT_BUILD_DIR, if used, must stay inside the repo, for example .next-local. The database path is the part you still have to get right yourself.

Three workflows, and what each one demands from you

InnoClaw presents three paths. The first is paper study: literature search across ArXiv, PubMed, bioRxiv and Semantic Scholar, summarization, and structured multi-role discussions with moderator, skeptic, librarian, reproducer and scribe roles. The role list is the substance here. A single-prompt summary collapses disagreement; assigning a skeptic and a reproducer as separate roles is an attempt to keep objections and reproducibility questions visible in the output. Whether the roles are enforced by separate model calls or by prompt structure is not stated in the material, so treat the distinction as unverified. The second path is the research workspace: chat over files with citations, file browsing and editing, an agent panel that runs multi-step tasks with tool calling, and importable scientific skills across domains such as drug discovery, genomics and protein science. Skill import arrived in v0.4.0 alongside model selection. The third path is remote execution: repository review with agent assistance, approval checkpoints before high-risk steps, job submission through Shell, Slurm or rjob, and monitoring across clusters. A later entry in the changelog adds a generic Kubernetes job scheduler that lets agents define, validate and execute containerized workloads with configurable job profiles. The approval checkpoint is the design decision worth noticing: the project acknowledges that an agent which can submit jobs needs a gate, and it puts that gate in the workflow rather than in documentation alone.

Getting it running: the commands and config keys that matter

The documented path is short. Clone the repository, run npm install, copy .env.example to .env.local, set WORKSPACE_ROOTS and at least one API key, create ./data, run npx drizzle-kit migrate, then npm run dev and open http://localhost:3000. Node.js 24 or newer is required, and package.json is named as the source of truth for that constraint; nvm users are told to run nvm install && nvm use. The environment example in the README shows two keys: WORKSPACE_ROOTS as an absolute path and OPENAI_API_KEY. The v0.3.0 release notes mention domestic models, which suggests provider choice beyond OpenAI, and v0.4.0 mentions model selection, but the README excerpt does not enumerate the supported providers, so check the settings screen rather than assuming. There is an optional CLI. npm link followed by innoclaw starts it, and innoclaw run --prompt "Summarize the current workspace" runs a single prompt. The CLI shares the same local app runtime as the web UI. When authentication is enabled it auto-starts the app, opens the browser login page on localhost, and stores a dedicated CLI session after sign-in; for trusted headless automation the README points at npm run dev:no-auth instead. Docker is supported through a separate path: copy .env.production.example to .env.production.local, edit the API key and WORKSPACE_ROOTS, then docker compose up -d. Upgrades follow git fetch --tags, git checkout vX.Y.Z, npm install, npx drizzle-kit migrate, npm run build, with the README asking you to read CHANGELOG.md before every upgrade and to diff .env.local against .env.example for new variables.

The limitation that should decide your deployment: shell execution and remote job submission

InnoClaw ships with shell execution and remote job submission, and the README says so in a security note rather than burying it. That combination is the real adoption boundary. An agent with file access and tool calling is one risk class; an agent that can submit Slurm or rjob jobs and, per the changelog, define and execute Kubernetes workloads is another. The project mitigates this with approval checkpoints for high-risk steps and with a documented trust boundary in SECURITY.md, plus an authentication toggle that lets you run with auth disabled for headless automation. That toggle cuts both ways: npm run dev:no-auth is the documented mode for trusted automation, and it is also the mode you must not expose. There is a second limitation that is less dramatic but easier to trip over. WORKSPACE_ROOTS paths must exist before startup, so a typo or an unmounted share produces an empty or broken workspace rather than a clear failure at the point of use. And the SQLite schema is upgraded by migration commands you run by hand; nothing in the material suggests an automatic migration on boot. Skip npx drizzle-kit migrate after a version change and you are running new code against an old schema. Finally, the release history is young. v0.2.0, v0.3.0 and v0.4.0 all landed on 2026-03-10 and 2026-03-12, which is a compressed burst rather than a long stabilization record. The changelog also shows feature work continuing into mid-2026, including the Kubernetes scheduler. Expect configuration surface to keep moving.

What InnoClaw is not: the alternative it should be compared against

The obvious alternative is a general-purpose agentic coding CLI such as Claude Code or an equivalent terminal agent pointed at a research directory. The difference in approach is structural. A terminal agent treats the filesystem as a working directory for the current session; context is whatever you feed it or whatever it greps, and there is no persistent index, no citation layer, and no database recording what a workspace contains. InnoClaw inverts that. The folder is registered in WORKSPACE_ROOTS, its contents are synced into an index, and answers are produced as RAG-backed citations over that index, with state persisted in ./data/innoclaw.db. The trade is real in both directions. InnoClaw gives you grounded, repeatable answers and a UI for paper study and cluster jobs, but it asks you to run a Node.js server, a SQLite database, a migration step and a model provider account, and it constrains you to folders you declared in advance. A terminal agent starts in seconds and works anywhere, but it will not tell you which file a claim came from unless you ask it to, and it will not hold a multi-role paper discussion as a first-class workflow. If your work is exploratory and single-session, the terminal agent is the lighter tool. If your work is cumulative and you need to show where an answer came from, the indexing layer is the point.

Maintenance cost, licence, and what to verify before you commit

InnoClaw is Apache-2.0, which permits commercial and private use and includes an explicit patent grant, with the usual obligations around retaining notices and stating changes. That is a permissive licence, and nothing in the supplied material adds field-of-use restrictions or a separate enterprise tier. This is not legal advice; read LICENSE and SECURITY.md yourself. The maintenance load is the part teams underestimate. You are operating a Next.js application, a SQLite file, a model provider integration and, if you use the third workflow, credentials and profiles for Shell, Slurm, rjob or Kubernetes. Upgrades are manual and ordered: fetch tags, check out the version, npm install, npx drizzle-kit migrate, npm run build. The README's instruction to diff .env.local against .env.example on every upgrade implies that configuration keys are added between releases, which matches a project that added model selection and skill import in a single version bump. Budget for that review step rather than treating upgrades as a pull and restart. The multi-language READMEs (Chinese, Japanese, French, German) and the bilingual release titles suggest an active non-English contributor base, which is relevant if you plan to file issues or follow design discussions. What the material does not tell you is how many people run this in production, how large a workspace index scales to, or what the agent's token cost looks like on a real corpus. Those are the questions to answer with a pilot on one folder before you move a lab onto it.

Editorial conclusion

Adopt InnoClaw if your research material already lives in server-side folders you control and you want citations, paper discussions and job submission in one self-hosted runtime. Do not adopt it if you need a managed SaaS, a hosted multi-tenant service, or a tool that cannot execute shell commands at all. Before installing, read SECURITY.md and confirm how you will run the app: npm run dev:no-auth for trusted headless automation, or the authenticated mode where the CLI opens a browser login on localhost and stores a dedicated CLI session. Then verify three things on your own machine: that every path in WORKSPACE_ROOTS exists, that DATABASE_URL points at local disk rather than NFS or CIFS, and that the SQLite schema at ./data/innoclaw.db migrated cleanly with npx drizzle-kit migrate.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SpectrAI-Initiative/InnoClaw on GitHub