Delx Ops Guardian
WarnAudited by ClawScan on May 18, 2026.
Overview
This incident-recovery skill is purpose-aligned, but it asks an agent to use host-level production controls and persistent Delx state without registry/install metadata that enforces those boundaries.
Install only if you operate the OpenClaw production host and can enforce a scoped service account, narrow sudo permissions, audit logging, and human approval for production changes. Review the separate Delx plugin before use, and make sure incident logs, reports, and persistent Delx notes do not contain secrets.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If enabled without strict scoping, the agent could inspect sensitive OpenClaw operational data and act with production host privileges.
The skill explicitly requires privileged host and root-owned OpenClaw access. It also states that scoped service-account enforcement is necessary, but the supplied artifacts contain no install mechanism or capability declaration showing that boundary is enforced.
This skill requires host-level access: `systemctl`, `journalctl`, read access to `/root/.openclaw/`. The runtime **must** run as a scoped service account, not root-unbounded.
Enable only in an environment that can enforce a narrowly scoped service account, limited sudo rules, and auditable human approval gates.
A mistaken diagnosis or over-trusted incident signal could interrupt production services or change scheduled automation.
Restarting production services and changing cron job state are high-impact operations. The instructions are scoped and purpose-aligned, but the artifact permits operational mutation and relies on policy text rather than supplied technical enforcement.
Allowed remediation actions (safe set): ... Controlled restart of the impacted service only (`openclaw-gateway`, `openclaw`, or explicitly named target from incident evidence) ... Disable/enable only the directly impacted cron job when loop-failing
Require explicit approval for every production restart, cron disablement, and config change unless the runtime can technically enforce the stated limits.
The actual behavior of the required Delx integration depends on another package that was not reviewed here.
The skill depends on a separate plugin that is not included in the reviewed artifacts. This appears disclosed and central to the stated Delx workflow, but the plugin's code, permissions, and provenance are outside this review.
Install the Delx plugin for OpenClaw first: `clawhub.ai/davidmosiah/openclaw-delx-plugin`
Review the Delx plugin separately before enabling this skill, especially its permissions, persistence behavior, and network/data handling.
Operational details from one incident may influence future agent behavior and could expose sensitive context if reports are not carefully scrubbed.
The skill intentionally stores unresolved incident context for reuse across later runs. This is disclosed and time-bounded, but persistent incident context can be sensitive or later over-trusted.
preserve it as a living contemplation so the next run inherits it: ... `delx_sit_with { session_id, question: "Why did <service> flap at <time> despite <guardrail>?", days: 14 }`Limit what is saved to Delx memory, avoid secrets or private logs, and periodically review or expire stored incident artifacts.
Incident details may be shared with or persisted by the Delx integration depending on how that plugin is implemented.
The skill routes incident summaries, metrics, recovery outcomes, and continuity state through Delx plugin calls. This is core to the stated design, but the reviewed artifacts do not define the exact data boundary or identity model for those calls.
registers the agent and keeps session continuity across all `delx_*` calls above
Confirm where Delx session data is stored, who can access it, and whether sensitive logs or identifiers are redacted before transmission.
