Claurst review: current documentation, older packaging evidence
Claurst's current README describes beta v0.2.0, while our recorded run exercised the npm packaging path for v0.1.7. That distinction matters when deciding what this review can establish: the documentation describes today's intended capabilities, and the run records an older installation step.
Claurst is a Rust terminal coding agent with provider choice and ACP editor integration. The project describes its origin as a clean-room reimplementation of Claude Code behavior. That is the project's account, not an independent legal assessment. Its claims about speed, memory efficiency and readiness for daily use were not measured here.
What our recorded run establishes
On September 27, 2026, our run used commit b0637c97ec34144387cbf2f74f65df6d16a6cef1, dated September 2, 2026, and selected the repository's npm/ directory. The recorded configuration was 3 CPUs, 8 GB of memory and image lab-node:22. The image label does not establish the actual Node runtime version.
The install step finished with exit code 0 in 15 seconds (15,238 milliseconds in the raw record). Its log contains an initial npm ci error because a suitable lockfile was absent. Later output shows the v0.1.7 postinstall downloading and extracting a Linux x64 release archive and reporting readiness. The record does not show a subsequent binary launch or version check. It therefore supports a completed packaging step, not a verified operational CLI. The initial command error also does not establish that Claurst is broken.
The harness recorded a dependency count of 0 and an installation footprint of 35 MB. These figures do not mean no binary was downloaded. npm audit recorded 0 critical, high, moderate or low advisories, with coverage unknown. Neither the dependency count nor the audit result establishes the safety of the native agent.
Build and tests were skipped because this npm package had no corresponding scripts. The Rust workspace was not compiled or tested. Provider calls, file edits, permission prompts, ACP sessions and coding workloads were not exercised.
The checkout measurements were 395 files, approximately 150,502 source lines and 14.2 MB, with 7 CI workflow files and a tests directory. These are historical checkout measurements, not current repository totals or passing-test counts. The harness recorded no Dockerfile or Compose file; that detection does not establish the absence of container setup.
What changed in the issue evidence
Issue 415 reported a workspace-containment race and explicitly identified b0637c9 as affected. The reporter described a path being checked inside the workspace, then replaced with a symlink before the file operation. Its CVSS 5.5 assessment belongs to the reporter; our packaging run did not reproduce the issue.
The supplied issue activity shows that maintainers closed issue 415 as completed through PR 433 on October 13, 2026. It also records subsequent commits referencing the report. This supports reporting its closed status, without claiming that we independently verified containment or established which release contains every related change.
Issue 395 reported DeepSeek V4 DSML envelopes appearing as text instead of executing tools, including in v0.1.7. It was closed as completed through PR 434 on October 13, 2026, with a referenced parser fix. DeepSeek users should verify tool execution on their chosen version and endpoint; this review has no live provider result.
Provider choice needs a compatibility check
The provider guide documents Anthropic as the default, hosted providers and local routes through Ollama, LM Studio and llama.cpp. Authentication and model-server setup sit outside our measured packaging step.
The same guide documents limits that matter when choosing a route: the openai provider uses Chat Completions and rejects o3, o4 and gpt-5-prefixed model IDs, directing GPT-5.x users toward the codex provider. It also says model whitelist and blacklist fields are parsed but not currently enforced. Do not treat those fields as an access restriction.
For ACP, the README documents claurst acp, JSON-RPC 2.0 over standard input and output, and a Zed configuration. It says current ACP sessions use the TUI's permission rules and send calls needing approval to the editor. Editor compatibility and permission behavior remain untested here.
Container setup requires its own review
Both the pinned and current README document a VS Code devcontainer. They describe GPG and SSH forwarding when configured on the host, a bind mount for local .claurst settings and session history, and Docker-outside-of-Docker support. The absence of a detected Dockerfile does not justify saying the project provides no container setup. Those host connections also deserve inspection before treating the devcontainer as containment for a trial.
The current README documents macOS Seatbelt restrictions for Bash commands, including workspace write limits and network blocking by default. This is a platform-specific documented feature, not a cross-platform security result from our run. Sharing, free mode, goals and ultracode remain marked experimental.
How to use the ratings
These are editorial evidence ratings, not benchmark scores. On this scale, 1 means substantial documented obstacles, 2 means partial evidence with major validation gaps, 3 means enough documentation for a bounded evaluation, 4 requires direct verification of the relevant behavior, and 5 requires broader repeated validation. Unknown adoption or compatibility does not earn a high score.
Setup earns 2/5 because packaging completed but binary operation was not checked. Documentation earns 3/5 because the supplied README and guides explain setup and important limitations. Community earns 2/5 because issue handling is visible, while support responsiveness and adoption were not measured. Maturity earns 2/5 because the project remains beta and current runtime behavior was not tested.
Which alternative fits the next evaluation?
OpenCode documents CLI installation and a beta desktop application. Consider it if you want to evaluate both interfaces. Its supplied README does not establish the earlier comparison's claim about DeepSeek DSML handling.
Crush documents LSP context, MCP extensions and model switching while preserving context. Consider it if those features lead your decision. Neither alternative was tested alongside Claurst here.
For Claurst, the useful next step is to record the exact installed version, verify that the binary launches, then check one provider's tool call and a harmless file edit in a disposable checkout. That would answer questions the stored packaging run leaves open.