Recurring issues & bugs¶
Named problems that span sessions or tools. Close or downgrade when resolved.
Open¶
Aye Robot — image + Telegram delivery (401 / send vs chat)¶
- Context: Crusty’s Aye Robot routine produces the comic idea; image generation and/or sending the image (or even a test text) to Telegram fails. Symptoms observed: HTTP 401 Unauthorized on at least one API; inbound Telegram (you → Crusty) still works, which feels contradictory.
- Why that’s not actually contradictory: Receiving your messages uses OpenClaw’s main Telegram integration (bot token + update pipeline). Outbound sends from a cron job, skill, or ad-hoc script often use a second code path — different env file, env var name, or no env at all under the scheduler — so they can hit
api.telegram.orgor the image provider with a missing/wrong/expired token while the chat bridge keeps working. - Split the failures: (1) Image API401 — bad/rotated xAI (or whichever provider) key, wrong
Authorizationheader, or key not visible in cron/launchd context. (2) Telegram Bot API 401 — wrongbot<token>in the send URL (typo, old token, truncated paste). Wrongchat_idusually yields 400, not 401 — so persistent 401 on Telegram almost always means token (or very rarely a revoked bot). - “Flux” vs
grok-imagine-image: If logs or tooling show Flux (Black Forest Labs) while you setgrok-imagine-image, the call is almost certainly not going to xAI’sPOST https://api.x.ai/v1/images/generations. Many agent stacks use a generic image tool (Replicate, fal, ComfyUI, etc.) with a fixed default model (often a Flux variant). Passinggrok-imagine-imagethere may be ignored, stripped, or rejected by a schema that only allows that provider’s IDs — so the stack “won’t adopt” the xAI name until the HTTP client base URL, Authorization (xAI key), and images/generations payload all target xAI, not a Flux gateway. Official xAI image id:grok-imagine-image(optionalgrok-imagine-image-pro); see xAI image generation. - Debug checklist (no secrets in logs): Confirm the same bot token string OpenClaw uses for inbound is what outbound code uses; run a manual
getMe/sendMessagefrom your login shell with explicitexport …; repeat from the exact environment the scheduled job uses (often emptyPATH/ no.zshrc); align one canonical env var and reference it everywhere; re-copy keys from provider dashboards if anything was rotated. - Next step: Unify credentials for image + Telegram send on the path Crusty’s job actually runs; verify with minimal curl from that environment before re-embedding in agent code.
- Links: projects/crusty, projects/ayerobot-comic (published channel), projects/openclaw-autonomy-org, glossary
Resolved¶
(None logged yet.)