Email Assistant
ReviewAudited by ClawScan on May 10, 2026.
Overview
This email triage skill is purpose-aligned, but it uses broad existing email-account access while making stronger privacy, read-only, and verification claims than the artifacts support.
Install only if you are comfortable with the agent reading your email through existing tools. Before use, configure the narrowest email profile possible, specify which account and folders may be checked, review all drafts manually, and do not enable dashboard or database storage unless you understand where that data will live.
Findings (4)
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.
The agent may read sensitive inbox and sent-mail content from any configured account exposed by the chosen email tool, and some of those tools may also have write or send capabilities.
The skill would use whatever email accounts and credentials are already available through local tools, but the artifacts do not clearly limit access to a specific account, folder, or read-only scope.
Email access is handled through the user's existing email tooling... himalaya CLI — IMAP/SMTP access... MCP email servers... gog CLI... Direct IMAP — via shell commands if other tools unavailable
Use a dedicated or least-privilege email profile where possible, specify the account, folders, and date range before each use, and avoid exposing SMTP/send-capable profiles unless truly needed.
A user may over-trust the skill's safety guarantees and give it broader email access than they otherwise would.
The provided artifacts do not show an external audit, enforcement layer, or read-only architecture that guarantees the agent cannot send email; the supported access methods include SMTP-capable tooling.
This skill has been audited by the Codex Security Team... The agent cannot send emails. This is an architectural constraint, not a configuration option.
Treat the draft-only and no-exfiltration statements as policy instructions rather than proven technical guarantees; review generated actions and constrain the underlying email tools.
If the dashboard path is used, sensitive email metadata and draft content could be retained in a persistent database rather than only local files.
The companion dashboard design can persist email summaries, sender PII, and draft bodies in a database or cloud-style backend, which expands the data handling beyond the local-only privacy language elsewhere.
For users scaling beyond local JSON files to a persistent database (e.g., Supabase PostgreSQL)... email_drafts... draft_body TEXT... Sender emails and names are PII
Keep dashboard/database storage disabled or local unless explicitly needed, require clear opt-in for any cloud backend, enforce row-level security, and avoid storing full email bodies or long-lived drafts.
The setup process modifies the local workspace and may reveal configured email account information to the agent during checks.
Setup asks the agent to run local shell commands that create files, copy a local health-check script, and inspect local email tooling; this is expected for setup but should still be reviewed.
Run from the workspace root... mkdir -p email-assistant/data/digests... cp "$SKILL_DIR/scripts/email-health-check.sh" email-assistant/scripts/email-health-check.sh... himalaya account list
Review the setup snippets before running them and run them only in the intended workspace.