Bytesagain X Manager
AdvisoryAudited by Static analysis on Apr 14, 2026.
Overview
No suspicious patterns detected.
Findings (0)
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 the user follows the schedule, the skill can publish tweets and like posts publicly on the account without reviewing each action, creating reputational, policy, and possible usage-cost risk.
The documentation encourages unattended recurring public likes and posts from the X account. Mention replies have an approval flow, but scheduled posts and likes do not show the same per-action confirmation.
Recommended Cron Schedule ... `0 9,13,17,21 * * * like` ... `5 10 * * * post --index 0` ... `5 15 * * * post --index 1` ... `5 20 * * * post --index 2`
Keep post and like commands manual unless this automation is explicitly desired; add a dry-run mode, per-post approval, hard rate caps, and a clear rollback/disable procedure before using cron.
Using behavior intended to appear human or avoid detection can violate platform rules and could result in account restriction or loss of trust.
The artifact explicitly frames randomized delays as avoiding bot detection, not merely as rate limiting. That is a stealth/abuse-oriented instruction for public social-media automation.
Bot-detection avoidance: multiple sends staggered 30–90s randomly
Remove anti-detection framing and implement transparent rate limiting/backoff that complies with X automation policies.
Anyone or any process with these environment variables could post, like, or reply as the configured X account and send Telegram bot messages.
These credentials are purpose-aligned for X posting, xAI draft generation, and Telegram approval messages, but the X token grants write authority over the account.
`X_ACCESS_TOKEN` ... `account-specific, Read+Write`; `XAI_API_KEY` ... `TG_TOKEN` ... `TG_CHAT` ... required
Use a dedicated X app/account where possible, grant only the needed scopes, store env vars securely, and rotate/revoke tokens if the skill is removed or no longer trusted.
Stale or manipulated pending reply data could remain on disk and later be used for a public reply, and users may not find it through the documented /tmp state path.
Public mention text and AI-generated draft replies are persisted under the user's home directory and later reused to send replies. This differs from the /tmp pending file documented in SKILL.md, making retention and review boundaries unclear.
PENDING_FILE = os.path.expanduser("~/.local/share/x-manager/pending-replies.json") ... "original": tweet["text"], "draft_reply": f"@{author_name} {draft}" ... reply_text = p["draft_reply"]Document the actual state path, make `status` read the same queue, expire pending replies, show the exact reply before sending, and provide a cleanup command.
It is harder to verify the maintainer, dependency expectations, and credential requirements before granting account access.
The registry/provenance metadata is incomplete for a skill that actually requires sensitive credentials and runs local scripts. The behavior is disclosed in SKILL.md, but the registry contract is weaker than expected.
Source: unknown; Homepage: none; Required env vars: none; Primary credential: none; Install specifications: No install spec
Verify the publisher independently, review the scripts before use, and require the package to declare its credentials, dependencies, source, and version consistently.