gmail-cleanup

The supplied code does not implement cleanup actions; it performs a read-only scan of Gmail inbox messages since the last run and updates scan state. While inbox triage/scanning is consistent with part of the description, the prominent declared behaviors—approval on Telegram, drafting replies, and archive/trash after approval—are absent from this chunk. Also, the code clearly depends on Gmail-related credentials and local state/config files, which is inconsistent with the empty declared permissions list. This is therefore a description/behavior mismatch for the provided code chunk.

The declared purpose centers on Gmail cleanup actions with Telegram used as an approval mechanism. The actual code chunk is only a notification sender: it reads text and sends it to Telegram through OpenClaw. It does not access Gmail, classify emails, draft replies, or enforce approval before mailbox actions. While Telegram notification could be a supporting component of the broader skill, this specific chunk performs an undeclared messaging capability and does not implement the described primary behavior, so the description does not accurately represent this code chunk.

The supplied code chunk is a read-only scanning component, not a full approval-gated cleanup skill. It accesses Gmail data by running gog gmail search and gog gmail get, extracts message metadata/body snippets, and writes results to state/gmail-cleanup/latest.json. The script explicitly states and enforces that it performs no mutations. There is no code for sending Telegram messages, waiting for approval, drafting replies, or archiving/trashing emails. This is a material mismatch because the declared description presents a user-approved inbox cleanup system with reply drafting and post-approval actions, while the actual code only gathers candidate messages for later classification. Additionally, the declared permissions are empty, but the code clearly reads Gmail content, which is an accessed resource inconsistent with that declaration.

This duplicate finding points to the same credential-handling issue: the workflow depends on access to a sensitive keyring secret during execution. In a skill that can invoke shell commands and external tools, any unexpected subprocess, debug output, or misconfiguration can leak that credential and broaden compromise beyond this skill.

This duplicate finding points to the same credential-handling issue: the workflow depends on access to a sensitive keyring secret during execution. In a skill that can invoke shell commands and external tools, any unexpected subprocess, debug output, or misconfiguration can leak that credential and broaden compromise beyond this skill.

This is the same underlying secret-handling weakness at a second matched token. The context is not overtly malicious, but the combination of email access, shell execution, and ambient credentials increases the blast radius if the password is exposed.

This is the same underlying secret-handling weakness at a second matched token. The context is not overtly malicious, but the combination of email access, shell execution, and ambient credentials increases the blast radius if the password is exposed.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

The skill declares no explicit tool scope or permissions despite describing capabilities that require shell execution, filesystem writes, network access, and access to environment secrets. That mismatch weakens containment and review because a runtime may grant broader-than-expected powers to a skill handling email and Telegram actions.

The audit log path is derived from GMAIL_CLEANUP_STATE, which is environment-controlled, and the script appends to that path without validating that it remains within an expected directory or is not a symlink. If an attacker can influence the environment in the execution context, they may redirect writes to unintended files, causing log forgery or clobbering of arbitrary writable files.

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Data from a source is assigned to a variable that is later passed to a sink, creating a variable-mediated taint flow.

Data from a source is assigned to a variable that is later passed to a sink, creating a variable-mediated taint flow.

The comment says 'Credentials: GOG_KEYRING_PASSWORD from the environment ONLY,' which strongly suggests environment-only configuration, but the script then loads operational configuration from a JSON file at L18, L26, L37, and L41. While this is not a dangerous contradiction by itself, the inline documentation overstates the extent to which runtime inputs are environment-only.