Server Watchdog

ReviewAudited by ClawScan on May 10, 2026.

Overview

This mostly matches a server watchdog, but the included persistent MongoDB watchdog can send alerts to a hard-coded Telegram chat unless the user overrides it.

Review and edit the script before deploying it. Set your own TELEGRAM_CHAT_ID or disable Telegram, confirm the service name, paths, and restart limits, use secure SSH practices, and deploy only on servers where you intentionally want persistent automatic restarts.

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.

Medium

#ASI07: Insecure Inter-Agent Communication

What this means

Server outage details, crash reasons, and operational status could be sent to a hard-coded Telegram chat instead of the user’s intended chat.

Why it was flagged

The script sends Telegram messages and falls back to a fixed chat ID if the user supplies only a bot token, so alerts may go to an unexpected recipient.

Skill content

chatId: process.env.TELEGRAM_CHAT_ID || '1663667034',
    enabled: true,
...
    hostname: 'api.telegram.org',
    path: `/bot${CONFIG.telegram.botToken}/sendMessage`

Recommendation

Remove the hard-coded chat ID, require an explicit TELEGRAM_CHAT_ID, document the Telegram configuration, and keep notifications disabled until the destination is verified.

Medium

#ASI02: Tool Misuse and Exploitation

What this means

If deployed on the wrong host or with the wrong service name, it could interrupt a database service.

Why it was flagged

The watchdog uses shell execution to stop and start a Windows service. This is consistent with auto-healing, but it is a powerful operational action.

Skill content

exec(cmd, { timeout: 30000 }, ...)
...
await execCmd(`net stop "${CONFIG.service.name}"`);
...
await execCmd(`net start "${CONFIG.service.name}"`);

Recommendation

Deploy only on authorized servers, review the configured service name and restart limits, and run with the least privileges needed for service control.

Medium

#ASI10: Rogue Agents

What this means

The watchdog may keep monitoring and taking restart actions until the user explicitly disables or removes it.

Why it was flagged

The documented deployment makes the watchdog persistent under PM2, so it can continue running and restarting services after setup.

Skill content

Start: `pm2 start mongodb-watchdog.js --name mongodb-watchdog`
4. Save: `pm2 save`

Recommendation

Document how to stop and uninstall the PM2 process, and deploy it only when persistent monitoring is intended.

Medium

#ASI03: Identity and Privilege Abuse

What this means

Users could expose credentials or connect to an impersonated server if they copy this pattern without safeguards.

Why it was flagged

The password-based SSH example disables host key checking and embeds a password placeholder in an expect script. SSH access is expected, but this pattern weakens connection verification.

Skill content

spawn ssh -o StrictHostKeyChecking=no user@host "COMMAND"
...
"password:" { send "PASSWORD\r"; exp_continue }

Recommendation

Prefer SSH keys, keep host key checking enabled, avoid putting passwords in command history or scripts, and scope server credentials narrowly.

Low

#ASI04: Agentic Supply Chain Vulnerabilities

What this means

Future installs could pull a different mongodb package version than the one originally tested.

Why it was flagged

The manual setup installs an unpinned npm dependency. This is normal for a simple deployment guide but leaves dependency version/provenance to the user.

Skill content

Install: `npm init -y && npm install mongodb`

Recommendation

Pin dependency versions, use a lockfile, and review the package source before deployment on production servers.