Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
OpenClaw Harness
v1.0.3Cross-session context manager for AI agents with checkpoint/snapshot, Build-Verify-Fix closure, and entropy management (GC). Use when: (1) creating a task ch...
⭐ 0· 109·0 current·0 all-time
by蓝宙@lanzhou3
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The name/description (checkpointing, verify, GC, progress) align with the provided scripts and documentation. The package also includes helper scripts to initialize/package skills which is plausible for a developer-focused harness. However the implementation relies on system tools (node, jq, openssl, sha256sum) and an external 'memory-palace' component at an absolute path (/root/.openclaw/...), none of which are declared in the skill metadata — this is an incoherence between declared requirements (none) and actual capabilities/dependencies.
Instruction Scope
SKILL.md tells the agent to run harness commands that operate on and modify local files (create/restore/delete checkpoints, compress MEMORY.md, run 'harness verify' etc.) — that is expected. But the verify subsystem supports 'command' checks that run arbitrary shell commands (e.g., 'npm run build' via a rule) which means the skill can execute arbitrary commands in the workspace when asked; SKILL.md exposes CLI options that accept JSON rules from the caller. The gc-agent can run as a daemon and will read/write/trim files across .harness and, via memory-palace integration, read MEMORY.md and invoke a node-based archiver. The instructions are not explicit about the required binaries or the fact that verification can execute arbitrary commands — this broad, under-documented power is a risk.
Install Mechanism
No install spec is provided (instruction-only), which is lower risk by itself. But the skill ships many executable scripts in-bin and libs; there is no documented dependency list or installer. That means users may run these scripts without realizing they require node/jq/openssl and may call other binaries. No remote download URLs are used in the install spec (none present), so there is no obvious remote-exec install risk, but missing declared dependencies is a usability/security mismatch.
Credentials
The registry metadata declares no required environment variables or credentials, but the runtime code references and uses several environment/config variables and hard-coded paths: OPENCLAW_WORKSPACE, MEMORY_PALACE_BIN, HARNESS_DIR, and defaults to /root/.openclaw/workspace and /root/.openclaw/workspace/skills/memory-palace/bin/memory-palace.js. The scripts also expect and call system tools (node, jq, openssl, sha256sum). Requesting/assuming access to /root/.openclaw (an absolute path outside a project directory) is disproportionate to a tool described as a local workspace harness and could grant access to data outside the immediate project.
Persistence & Privilege
always:false (normal). The skill includes a GC agent that can run as a daemon (gc-agent.sh) and create lock/log files under .harness; running it as a background service is optional and under user control. Autonomous model invocation is allowed by default (disable-model-invocation:false) — not an exceptional privilege on the platform, but combined with the ability to run arbitrary commands via verify and to run a daemon, this increases the blast radius if misused. The skill does not assert it will modify other skills' configurations.
Scan Findings in Context
[node_exec_memory_palace] expected: The scripts call a 'memory-palace' node binary to archive MEMORY.md. Archiving memory is consistent with the described purpose, but the code hard-codes an absolute path (/root/.openclaw/workspace/skills/memory-palace/bin/memory-palace.js). That path/assumption is not declared in metadata and implies access to a workspace outside the project.
[command_execution_via_verify] expected: The verify subsystem supports rules of type 'command' (e.g., run 'npm run build'). Executing build/test commands is consistent with 'verify' but it effectively allows arbitrary command execution in the host environment when verification rules are provided/constructed — a powerful capability that must be used carefully.
[jq_usage] expected: Scripts use jq for JSON parsing when available, falling back to fragile grep/sed. Declaring jq as an optional dependency would be expected; its absence from metadata is an omission.
[openssl_rand] expected: ID generation prefers 'openssl rand -hex 8' and falls back to date-based IDs. Use of openssl is reasonable but not declared.
[absolute_root_path_reference] unexpected: Multiple files reference /root/.openclaw/workspace. Relying on absolute root paths is unexpected for a per-project harness and raises concerns about unintentionally touching data belonging to other users or system-wide agent state.
What to consider before installing
This skill appears to implement the advertised checkpoint/verify/GC features, but there are important mismatches and risks you should consider before installing or running it:
- Missing dependency/declarations: The code expects node, jq, openssl and other common utilities, but the skill metadata lists none. Verify/install those dependencies yourself or run the scripts in an environment where missing dependencies won't cause surprises.
- Review and restrict verify rules: The 'harness verify' mechanism can execute arbitrary shell commands via 'command' rules. Never run verify with untrusted rules. Inspect any --rule JSON before use and prefer file/pattern checks over command checks unless you trust the commands.
- Inspect memory-palace integration: The GC agent will try to call a 'memory-palace' node binary at an absolute path (/root/.openclaw/...). That may access workspace-level or root-owned data. If you don't run memory-palace, set ARCHIVE_PRIORITY=local or point MEMORY_PALACE_BIN to a trusted binary, or disable compression.
- Run in isolation first: Test the skill in a throwaway container or dedicated VM and run gc with --dry-run initially. Do not enable daemon mode until you audit behavior.
- Do not blindly install hooks: The docs mention pre-commit hooks that run harness verify and linter on commits — review those hooks before adding them; they could block commits or run commands during commits.
- Ask the publisher for provenance: There is no homepage or clear source origin. If you need to use it in production, request a signed release, dependency list, and explicit explanation of why absolute paths are used and what memory-palace does.
If you proceed, prefer changing defaults to local-only operations, disable daemon mode, run GC only with --dry-run first, and ensure the .harness root is inside the project directory (not /root) to avoid touching unrelated data.Like a lobster shell, security has layers — review code before you run it.
latestvk979e5fzec6kdy1yzp1rfdfx4983ssn8
License
MIT-0
Free to use, modify, and redistribute. No attribution required.