# A snapshot per run, and three images documented against six built

> Siclaw is a TypeScript agent for SRE teams whose defining constraint is that it never changes what it investigates: it gathers evidence, forms hypotheses, validates them, and returns a root-cause analysis. Everything else follows from that, including a CLI that materialises its skills and credentials into a per-run directory and deletes it on exit. The packaging tells a rougher story, with a manifest version two minor series behind the tags.

**scitix/siclaw** — AI-powered SRE platform — read-only infrastructure diagnostics with deep investigation, security governance, and team collaboration

- Repository: https://github.com/scitix/siclaw
- Website: https://siclaw.ai
- Stars: 238 · Forks: 32
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-24 · Updated: 2026-08-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/scitix-siclaw

## Read-only is stated in the pitch, the features, and the architecture

The positioning is one sentence: a read-only investigation copilot for DevOps and SRE teams, built for read-only infrastructure diagnostics. What that means operationally is spelled out as a loop, gather evidence, form hypotheses, validate them, and return a clear root-cause analysis without changing your environment directly. The constraint then reappears twice more, which is unusual and deliberate. It is a named feature, Read-Only by Default, described as investigating and recommending next steps. And the architecture note says the Agent Brain runs a Deep Investigation Engine against its bound capabilities and is read-only across every target it touches. So the guarantee is not a setting you enable; it is the property three separate parts of the document agree on, and everything else in the design is downstream of it.

## Four phases, and the memory that compounds them

The investigation itself is described as a four-phase workflow covering evidence gathering, hypothesis testing, and root-cause analysis. Two features sit on top of that loop and are where the value accumulates. Investigation Memory learns from past incidents to improve future investigations, so the fourth phase feeds the first on the next run. Reusable Skills turn repeated diagnostic playbooks into reviewable runbooks, which is the same content promoted from a habit into something a colleague can read and change. The hosted preview exists to demonstrate exactly those two without a cluster: it carries four specialist agents, recorded investigation sessions, and the built-in diagnostic skill set. The rest of the feature list is plumbing around them, covering team workflows with shared credentials, channels, triggers, and scheduled patrols, plus extensibility through MCP and multi-channel access. One feature is aimed squarely at the people who have to justify the tool: Agent Tracing exports agent behaviour, specifically LLM calls, tools, and tokens, to Langfuse, Phoenix, or any OTLP backend, and it is configured in the web UI and hot-reloaded live rather than requiring a restart. Read-only is easier to argue for when you can show the transcript of what the model did.

## A snapshot per invocation, and only that root removed

The headless CLI does not read the Portal database directly. It reads configuration through a local authenticated snapshot API, and each invocation materialises skills, knowledge, and credentials under a private run directory named .siclaw/.portal-snapshot/run-<random>/, removing only that root on exit. Two consequences follow. Web UI changes apply to the next invocation rather than the current one, so there is no live reconfiguration mid-run. And the cleanup is scoped, so a crash leaves a directory behind rather than a shared workspace in an unknown state. The fallback path is narrower than the happy path: when Portal is unavailable and no agent was selected, the CLI uses .siclaw/config/settings.json and local resources, but a selected agent must load successfully and snapshot failures stop execution rather than degrading.

## The terminal migration kept three behaviours and dropped two

There is a migration note about the terminal interface, and it is specific enough to be useful to anyone with scripts. A bare siclaw now shows help instead of starting anything, interactive investigations moved behind siclaw local, and the terminal slash commands and the setup wizard have been removed. One flag tightened as well: --continue now requires a new --prompt. What survived is called out explicitly, since existing --print --prompt scripts remain supported. That is a reasonable split, keeping the machine-facing path stable while removing the interactive path that was harder to script. The three-command non-interactive flow is the intended replacement:

```bash
siclaw agents
siclaw --agent sre-oncall --prompt "Why is pod nginx-abc in CrashLoopBackOff?"
siclaw --agent sre-oncall --continue --prompt "Check recent events"
```

A single configured agent is selected automatically, --agent is required once there are several, and missing input or model configuration produces an error rather than a setup prompt.

## SQLite locally, MySQL in the chart, and everything under .siclaw

Local and production differ in exactly one dependency, and the README is upfront about it. The local server is a lightweight web UI backed by SQLite, with no MySQL and no Docker required, started with a global install and a single subcommand. The Helm chart takes a MySQL URL instead. Data location is relative to the directory you launch from, which is why the quick start tells you to create a dedicated working directory first: the database defaults to .siclaw/data/portal.db and is overridable with a DATABASE_URL that accepts either a sqlite path or a mysql URL, and secrets land in .siclaw/local-secrets.json as auto-generated JWT, Runtime, and Portal secrets with 0600 permissions. On the network side the chart exposes only the Portal, on service port 3003 and NodePort 31003, while Runtime and AgentBox stay ClusterIP-only. The from-source route is also documented, and it is not a single command: clone, then npm ci with a Makefile target to build the portal web assets, then the package build, then npm link to register the siclaw command globally, with npm unlink siclaw -g as the documented uninstall. A fresh local workspace creates a bootstrap admin account with admin as both username and password, and the README tells you to change it in Account before doing anything else.

## The Makefile builds six images and the README documents three

The README says production deployment uses Helm plus three container images, runtime, portal, and agentbox. The Makefile names six: siclaw-runtime, siclaw-agentbox, siclaw-portal, siclaw-script-sandbox, siclaw-ocr, and siclaw-kbc-box, each taking a tag that resolves to the exact git tag when one exists and otherwise falls back to the manifest version, the short commit, and a dirty suffix. So three images are documented and six are built, and the three undocumented ones are the interesting half: a script sandbox, an OCR service, and a KBC box. The Makefile also injects OCI labels into every image for version, revision including the dirty marker, and a creation timestamp, defaults the registry to scitix, and makes help the default goal with target names extracted from annotated comments.

## The manifest says 0.1.4 while the tags say 0.3.25

The npm manifest carries version 0.1.4, while the recent repository tags are v0.3.25, v0.3.24, and v0.3.23, so the published package sits two minor series behind the source. That interacts with the tagging logic above, because the Makefile reads its version from the manifest: an image built from a clean tag uses the tag, and one built from a branch falls back to 0.1.4. The rest of the manifest is a good description of what the tool touches. The engine requires Node 22.19.0 or newer, the bin entry maps siclaw to a single ./siclaw.mjs shim, and the published file list is dist/, portal-web/dist/, that shim, skills/, settings.example.json, patches/, and scripts/install/. Dependencies include the Anthropic SDK, the Kubernetes client, the MCP SDK, four OpenTelemetry packages, sqlite-vec, ssh2, node-forge, prom-client, and mysql2.

## Conclusion

Siclaw suits an SRE team that wants an agent to gather and cross-check evidence against production without giving it write access, and that is willing to run it read-only first and widen its permissions later. It does not suit you if you want the agent to fix what it finds, because that is the one thing it is built not to do. Before adopting, check the published npm version against the git tags, since the manifest sits two minor series behind, and read the chart's port assignments before pointing it at a cluster.

## FAQ

### What is Siclaw?

An open-source AI agent for DevOps and SRE teams built for read-only infrastructure diagnostics. It gathers evidence, forms hypotheses, validates them, and returns a root-cause analysis without changing your environment directly, and it can be driven from the web UI, team chat channels, or a non-interactive CLI.

### What does read-only mean in Siclaw?

It is the core constraint, stated in the pitch, again as a named feature called Read-Only by Default, and again in the architecture note that the Agent Brain runs its investigation engine read-only across every target it touches. Siclaw investigates and recommends next steps rather than acting on them.

### How does the Siclaw headless CLI get its configuration?

Through a local authenticated snapshot API on the Portal. Each invocation materialises skills, knowledge, and credentials under a private .siclaw/.portal-snapshot/run-<random>/ root and removes only that root on exit, so Web UI changes apply to the next invocation rather than the current one.

### What does Siclaw need installed?

Node.js 22.19.0 or newer and npm, which comes with Node, plus kubectl only if you want it to investigate Kubernetes clusters. The local server is a web UI backed by SQLite and needs no MySQL and no Docker.

### How do I deploy Siclaw for a team?

With Helm plus container images. The chart is installed with `helm upgrade --install siclaw ./helm/siclaw` and takes a MySQL database URL, exposing the Portal on service port 3003 and NodePort 31003 while Runtime and AgentBox remain ClusterIP-only for internal traffic.

### What tracing does Siclaw support?

Agent tracing exports LLM calls, tools, and tokens to Langfuse, Phoenix, or any OTLP backend, configured in the web UI and hot-reloaded live. The npm manifest also pulls in four OpenTelemetry packages and prom-client, and the Slack and Lark SDKs appear among the optional dependencies.

## Sources

- [Official documentation](https://siclaw.ai)
- [Official README](https://github.com/scitix/siclaw#readme)
- [Project repository](https://github.com/scitix/siclaw)
- [Release notes](https://github.com/scitix/siclaw/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scitix-siclaw