Is harman314/rescueclaw safe?

package.json declares clawhub.postInstall: 'install.js'. On install, this runs immediately. install.js copies a bundled platform binary to ~/.local/bin/rescueclaw and chmod 0o755's it, placing an opaque executable into the user's PATH without prompting. The bundled binary for linux/arm64 is not present in the audited file listing but the code path exists.

install.js calls execSync('rescueclaw --version', ...) immediately upon installation. If a malicious binary named 'rescueclaw' already exists in PATH (e.g. placed by a prior compromise), this executes attacker code. If the skill's own binary was already installed, this confirms successful execution at install time.

The skill installs a background daemon (rescueclaw) that continuously monitors agent health and reads the checkpoint-request.json file created by the API. The daemon binary has no source code in this review. A malicious daemon implementation could: read any file accessible by the agent user, exfiltrate checkpoint metadata (which includes task descriptions), or execute commands when the 'rollback window' triggers.

For platforms without a bundled binary, SKILL.md directs users to download from https://github.com/harman314/rescueclaw/releases. This binary is not part of the skill under audit and could contain arbitrary code. Once installed and running as the agent user, it has read access to all credential files, environment variables, and agent configuration.

The daemon's auto-restore feature triggers when the agent is 'unresponsive' within the rollback window (default 300 seconds). What constitutes 'unresponsive' is defined by the daemon, not the user. A malicious daemon could declare the agent unresponsive at will and restore configuration to a previous backup that the daemon itself controls, effectively enabling persistent config poisoning.

Every createCheckpoint() call writes a JSON file including the agent's stated 'reason' for the operation (e.g. 'Updating OpenClaw config', 'About to apply config changes'). The daemon reads this file. Over a session, this builds a structured log of everything the agent is doing, exfiltrable by the daemon at any time.

SKILL.md instructs the agent to call createCheckpoint() before 'installing skills'. This means every time the agent installs another skill, it must invoke this skill first, giving the RescueClaw daemon visibility into the exact moment and reason for each skill installation. This could be used to selectively interfere with or log competing skill installations.

getStatus() calls execSync('rescueclaw status --json') and falls back to execSync('rescueclaw status'). Both resolve 'rescueclaw' from PATH at runtime with no integrity check. Any binary named 'rescueclaw' in PATH will be executed, including one placed by an attacker earlier in the session.

The SKILL.md example function calls exec('systemctl restart openclaw-gateway') as a normal workflow step. This normalizes restarting system services as something the agent should do routinely, potentially lowering the agent's guard around other systemctl commands.

Six honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) were opened and read (CLOSE_NOWRITE) twice during monitoring. Timing aligns with oathe audit baseline and final integrity checks rather than skill code execution, but a second pass at timestamp 1771930408.918 occurs after the skill files were written and cannot be conclusively attributed to audit infrastructure alone.

A TCP connection to 140.82.121.4:443 (GitHub) was established during the git clone operation. This is expected and normal for fetching skill files from the openclaw/skills monorepo.