Posta
ReviewAudited by ClawScan on May 10, 2026.
Overview
Posta appears to do what it claims, but it can act on public social accounts and stores session/API response data in predictable /tmp files, so it needs review before use.
Install only if you want the agent to manage Posta and connected social accounts. Prefer a revocable API token over email/password login, require approval before any publish/schedule/delete action, and clear or protect `/tmp/.posta_token` and `/tmp/.posta_last_response` after use.
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.
If invoked incorrectly, the agent could publish, schedule, change, or delete content on connected social accounts.
The helper exposes direct operations that can create, publish, schedule, update, cancel, or delete social-media posts. This is purpose-aligned for a social-media manager, but it is high-impact.
**Posts:** `posta_list_posts`, `posta_create_post`, `posta_create_post_from_file`, `posta_get_post`, `posta_update_post`, `posta_delete_post`, `posta_schedule_post`, `posta_publish_post`, `posta_cancel_post`
Use draft/preview workflows and require explicit user approval before publishing, scheduling, deleting, or updating posts or profiles.
On some systems, another local user or process could read or reuse the cached Posta session token and act on the user's connected social accounts.
Legacy email/password login stores a bearer JWT in a predictable global temporary-file path, with no visible chmod, keychain use, per-user cache directory, or cleanup.
POSTA_TOKEN_FILE="/tmp/.posta_token" ... echo "$token" > "$POSTA_TOKEN_FILE" ... token=$(cat "$POSTA_TOKEN_FILE")
Prefer a revocable `POSTA_API_TOKEN`; avoid legacy password login where possible; store cached tokens only in a user-private directory with restrictive permissions or a keychain, and delete `/tmp/.posta_token` after use.
Private social-account data or post analytics could remain on disk after the task and be read accidentally or by another local process.
Every API response is copied to a predictable `/tmp/.posta_last_response` file and left there for later access. Responses may include profile details, social account usernames, captions, analytics, or media URLs.
posta_sanitize_json "$tmpfile" > /tmp/.posta_last_response cat /tmp/.posta_last_response
Avoid persistent response files by default, or store them in a permission-restricted per-user cache and delete them after the command finishes unless the user opts in.
Users may misunderstand where the skill looks for credentials or store keys in places they did not intend the agent to use.
This credential-discovery statement conflicts with the main skill documentation and helper source, which say shell profiles are never accessed and list different dotenv files. The inconsistency can confuse users about which local files may be read.
**Auto-discovery:** The skill searches env vars, `.env.development`, `~/.zshrc`, `~/.bashrc`, and `~/.posta/credentials`
Update all documentation to match the implemented fixed credential-source list, and clearly state which files are read and which are never accessed.