IMAP IDLE Watcher
WarnAudited by ClawScan on May 18, 2026.
Overview
The skill matches its email-watcher purpose, but it installs a persistent system service that can run arbitrary shell commands on incoming email, likely with elevated privileges.
Install only if you are comfortable running a persistent email-triggered automation service. Use a dedicated low-privilege user or user-level service, set narrow filters, review any handler script before enabling it, avoid passing passwords on the command line on shared systems, and revoke the app password when you uninstall.
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.
A misconfigured or overly broad handler could modify files, call external services, or run expensive/destructive actions whenever matching email arrives.
The daemon executes the configured command through a shell when new mail is detected. This is central to the skill, but it gives email events the ability to trigger arbitrary local shell commands with no per-event approval.
result = subprocess.run(
ON_NEW_MAIL_CMD,
shell=True,
capture_output=True,
text=True,
timeout=300,
env=env,
)Use a minimal reviewed handler, avoid shell metacharacters where possible, set sender/subject filters, and test with a harmless command before enabling automation.
Incoming email could trigger a command running with more local system privilege than the user expects.
The generated systemd unit shown has no User= restriction. As a system service under /etc/systemd/system, it will normally run as root, so the daemon and its configured handler command may inherit elevated privileges.
[Service] Type=simple EnvironmentFile=$env_file ExecStart=$(command -v python3) $DAEMON_SCRIPT Restart=always StandardOutput=journal StandardError=journal
Run it as a dedicated unprivileged user or user-level systemd service, add a User= directive, and avoid installing handlers that need root unless absolutely required.
Anyone who obtains the env file or the app password may be able to access the mailbox via IMAP.
The setup stores the IMAP account and app password in a local environment file with restricted permissions. This is expected for an IMAP watcher, but the app password is still a sensitive mailbox credential.
IMAP_ACCOUNT=$ACCOUNT IMAP_PASSWORD=$PASSWORD IMAP_HOST=$HOST ... chmod 600 "$env_file"
Use an app-specific password, keep the env file restricted, prefer interactive password entry over command-line arguments on shared systems, and revoke the app password when uninstalling.
The watcher and its handler can continue running in the background after the initial setup session.
The skill intentionally creates a long-running watcher that keeps reconnecting. This persistence is disclosed and purpose-aligned, but users should understand that it will keep operating until stopped or uninstalled.
Runs as a systemd service with auto-reconnect.
Monitor the service with systemctl and journalctl, and stop or uninstall it when the automation is no longer needed.
Email subjects and senders may appear in system logs or influence downstream handler behavior.
Email sender and subject metadata are passed into the handler environment and written to logs. This is expected for the watcher, but those fields come from external email and may contain sensitive or untrusted text.
env["MAIL_FROM"] = meta["from"]
env["MAIL_SUBJECT"] = meta["subject"]
log.info(f"📬 New mail: {meta['from']} — {meta['subject']}")Treat email metadata as untrusted input, avoid feeding it directly into shell commands, and review logs for sensitive information exposure.