Microsoft 365 / Outlook CLI for calendar and email. Use when managing Outlook calendar (view, create, update, delete events, find meeting times, respond to invitations), sending/reading emails, or searching for people/rooms in the organization.
Security Analysis
medium confidenceThe skill's stated purpose (a CLI that automates Outlook via a local browser session) is plausible and mostly coherent, but the instructions reference tools, environment variables, and filesystem behavior that the skill metadata does not declare—this mismatch and the persistent browser automation recommendation warrant caution.
Name/description (M365/Outlook CLI) match the runtime instructions: the SKILL.md documents calendar, mail, and people/room operations via a local 'clippy' CLI that automates the M365 web UI. Requiring a 'clippy' binary is proportional to the described purpose.
Instructions tell the agent/user to run the 'clippy' binary to read/send emails, create/update/delete events, download attachments to arbitrary paths (e.g., ~/Downloads), and to keep a browser session alive by periodically refreshing. These actions are expected for an email/calendar CLI, but they involve reading/writing local files (e.g., ~/.config/clippy/keepalive-health.txt and the profile dir) and opening a browser session that has access to the user's mailbox, which is sensitive. The SKILL.md also references an env var (CLIPPY_PROFILE_DIR) that is not declared in the metadata.
The skill is instruction-only (no install spec), but the SKILL.md install steps require 'git' and 'bun' (bun install, bun run) to build/link the CLI from https://github.com/foeken/clippy. The metadata only declares the 'clippy' binary as required; 'git' and 'bun' are not listed. Building this project will likely pull Playwright and download browser binaries at install time (large downloads, executes code fetched from GitHub). The lack of an install manifest or declared build dependencies is an incoherence and increases risk.
Metadata declares no required env vars or credentials, which is consistent with the approach (interactive browser login). However SKILL.md documents CLIPPY_PROFILE_DIR and expects persistent session files under ~/.config/clippy. While no cloud credentials are requested, session cookies stored locally grant broad mailbox access — an expected but sensitive capability. The skill does not declare these config path dependencies in metadata.
The skill does not request always:true and is user-invocable. SKILL.md recommends running a keepalive process (systemd/launchd) to maintain a browser session, which creates a persistent local process with regular access to the web session and mailbox data. Autonomous invocation by the agent is allowed (default), so if the binary exists the agent could run clippy commands without further consent — this is normal but combined with recommended persistent keepalive increases the long-term blast radius.
Guidance
This skill appears to be what it claims (a CLI that automates Outlook via a local browser session), but there are mismatches you should consider before installing: (1) The SKILL.md install steps require 'git' and 'bun' to build/link clippy from GitHub, but those tools are not listed in the skill metadata—verify you have the build toolchain and review the repository before running. (2) Clippy uses Playwright/browser automation and stores session/profile data under ~/.config/clippy (or a directory you set with CLIPPY_PROFILE_DIR); those session files (cookies/tokens) effectively give full access to your mailbox—only use with accounts you trust on the machine. (3) The instructions recommend running a persistent keepalive (systemd/launchd), which creates a long-running process that keeps a browser session alive; consider the security implications of a persistent process with mailbox access. (4) If you want more controlled access, prefer an OAuth/App-based integration (Microsoft Graph) rather than browser automation. Before installing: review the upstream repo code (https://github.com/foeken/clippy), confirm the source is trustworthy, ensure you understand where session data will be stored, and avoid using it with highly sensitive accounts or on shared machines.
Latest Release
v1.2.0
Session persistence fix: use storageState instead of persistent context
More by @foeken
Published by @foeken on ClawHub