The description advertises an 80 percent claim the readme explicitly withdrew

The repository description advertises the figure the evaluation section retired

The description field beside the repository name advertises an eighty percent reduction in priority-zero incidents. The evaluation section of the readme says something quite different about that number. It records twenty hand-built tool-selection scenarios, gives a safety-hit rate of ten out of twenty for a single-stage design against eighteen out of twenty for the two-stage one, and states in its own words that going from fifty to ninety percent is a rise of forty percentage points rather than a reduction of anything. It adds that the figures were not re-measured after the fixes landed and must not be read as general task accuracy, and it explains why the old number is gone: the earlier material described the same two remaining failures as both incidents and safe aborts, so counting them twice produced the headline. The readme declines to quote the figure. The repository description still quotes it. The same table carries a second column nobody has argued about: mean decision time goes from 19.33 seconds to 23.88, roughly a quarter more latency, presented as a plain number with no commentary. The script behind both numbers is criticised in the next paragraph for using simulated tools and for not checking the new credential protocol at all.

The audit trail is partial by design and the example command names one machine's session

Five event types are logged: model input, tool call, tool result, assistant message and system action. What is stored is deliberately reduced. A model input event records how many messages there were, not the messages. A tool result event records the first two hundred characters of the result. Credentials appearing in arguments or previews are masked, which is the right call. The queue is bounded at four thousand and ninety-six entries and drops new events when full while incrementing a counter, and a shutdown drains it. The file then states plainly that you may not claim full traceability or replay from this, because a crash can lose events. The documented way to follow the log is a tail command on a file whose name is a machine-local session identifier belonging to the author, which is a small thing to change and an odd thing to have in a readme.

One global profile file, and exactly-once is explicitly disclaimed

Two sentences do more work than any feature list in the file. The first says the SQLite checkpoint saves recoverable graph state and does not provide exactly-once execution of external tool side effects. The second says the long-term profile is currently a global file and is not yet isolated per user. Both are in the open, and both matter because the built-in tool set includes reading and overwriting that profile, writing files, and running a command after validation. So the project's memory of who you are is one file that any session can overwrite, and the crash-recovery story covers the graph rather than the effects of what the graph did. That is a coherent design for a single-machine command line tool, which is what the file says this is, rather than a server. Read the scoping sentence and the reliability sentence together and the supported deployment shape is unambiguous.

Turn counting is not token counting, and the two thresholds in the code disagree

The description advertises a two-watermark memory. The readme explains what the two watermarks actually are and then undercuts the framing in three sentences. Context trimming cuts complete turns that begin with a user message. The trimming helper has default parameters of eight and four. The agent node explicitly passes forty and ten. The thresholds can be changed where they are called in code, but there is no configuration option for them, and because trimming happens after the threshold is reached it is not a fixed every-forty-turns trigger either. And then the sentence that should be quoted: controlling by turns is not controlling by tokens. A turn with a one-word question and a turn with a pasted file are the same unit to this mechanism, so the watermark tracks conversation shape rather than context budget, and the two defaults disagreeing means a reader of the code has to know which call site is live.

The credential travels in plain text inside the instruction document

import re
from cyberclaw.core.skill_loader import load_dynamic_skills

# 先安装至少一个技能到 workspace/office/skills/<技能名>/
skill = load_dynamic_skills()[0]
config = {"configurable": {"thread_id": "demo-session"}}
manual = skill.invoke({"mode": "help"}, config=config)
token = re.search(r"help_token: ([A-Za-z0-9_-]+)", manual).group(1)

result = skill.invoke(
    {"mode": "run", "command": "echo {baseDir}", "help_token": token},
    config=config,
)
print(result)

The mechanism itself is well built. The help step returns the full instructions plus a random token. The run step must carry it. The loader checks the session identifier, the skill identity, the path of the instructions and a hash of their contents, all against a trusted run configuration. The token lives three hundred seconds, is consumed atomically before the executor runs, and concurrent reuse of the same token passes at most once. Missing, cross-session, cross-skill, expired, replayed or stale tokens are all refused. What the example above shows is how the token travels: it is embedded in the human-readable instruction text and recovered by pattern-matching it back out. Anything that can read the help output can read the token.

The guard constrains the dynamic skill interface, and the shell tool is outside it

One paragraph is the most important in the file and it is easy to skim. It says the credential proves that the session obtained that version of the instructions, and that it does not prove the model understood them, executed safely, or that the user authorised anything. Then it names the boundary: this flow constrains the dynamic skill interface, and the built-in shell tool is a separate tool. So the two-stage mechanism guards the path where a model loads third-party instructions, and does nothing for the tool that runs a command in the working directory after its own validation. That is a defensible split, since the two interfaces have different provenance, but it means the security property people will quote about this project applies to a subset of its capabilities. The boundary section makes the matching point about the shell tool: it runs with host permissions, the working directory is only a directory, and path checks cannot replace a container or a low-privilege account.

Fourteen dependencies, every one a lower bound, no lockfile

The requirements file lists fourteen packages and not one of them has an upper bound. Four are terminal-interface libraries, five are from the LangChain ecosystem, two are provider software development kits, two are storage libraries and one is a validation library. There is no lockfile anywhere in the tree. The project also declares a strict interface contract of its own: a token that expires after three hundred seconds, a hash over instruction text, an atomic single use. Building that kind of ordering guarantee on a graph of libraries that can move under you in any minor release is a choice, and the file makes it silently. Two smaller consequences of the same file: the manifest is a setup script with a hand-written requirements parser that keeps every non-comment line verbatim, and the Anthropic software development kit is a hard requirement even though the Anthropic path needs a second LangChain package the file does not list.

The shipped default configuration points at one vendor's coding endpoint

The example environment file sets the default provider to one of the Chinese cloud vendors and the default model to a model from that vendor's family, with the base address pointing at that vendor's coding endpoint rather than its general one. Seven provider names are offered in a comment, and the capability table describes three code paths: the OpenAI-compatible interface, an Anthropic branch and an Ollama branch. So four of the seven named providers ride the OpenAI-compatible route, one has its own branch, one is a local runtime, and the catch-all option is unaccounted for. The file is candid that the Anthropic and Ollama branches need extra packages that the requirements file does not list and that those optional branches have not been verified against a real API in the current regression. What it does not mention is that the out-of-the-box default is a third-party coding endpoint rather than any of the providers named in the readme's own prose.

Editorial conclusion

CyberClaw is worth reading if you are building an agent harness and want one mechanism designed rather than assumed, because the credential is single-use, time-bound, atomically consumed and tied to the hash of the instruction text it authorises, and the boundary section is unusually honest about what none of that proves. It is not a sandbox and does not pretend to be one, since the file says so in three separate bullets about host permissions, subprocess trees and absent resource quotas. It is also not a multi-user product, since the long-term profile is one global file that two built-in tools overwrite. Before you build on it, decide whether turn-based context trimming is acceptable for your prompts rather than token-based, pin the fourteen unbounded dependencies yourself, and note that the guard covers the dynamic skill interface while the shell tool sits outside it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. ttguy0707/CyberClaw on GitHub