Fix: Telegram "ENOENT" Reply Crash
The "Greedy Regex" Logic
The OpenClaw Telegram plugin uses a pattern-matching system to detect if an agent wants to send a file (e.g., an image or voice message). In earlier versions, this regex was too aggressive. If your agent replied with descriptive text like <audio> rendering... or mentioned a Linux-style path in its narration, the plugin would attempt to fs.open() that text as a file, resulting in a fatal ENOENT (No such file or directory) error.
If your bot suddenly stops replying and the logs show telegram tool reply failed: Error: ENOENT, your agent is likely talking too much about files that don't exist.
Next Step
Fix now, then reduce repeat incidents
If this issue keeps coming back, validate your setup in Doctor first, then harden your config.
Symptoms
Solution 1: Update OpenClaw (Permanent Fix)
OpenClaw v2026.2.28+ introduced a refined file detection logic that requires explicit file:// prefixes or specific metadata tags, preventing plain text from being mistaken for paths.
npm install -g openclaw@latest\nopenclaw gateway restart
Solution 2: Sanitize Agent Prompt
If you cannot update, you can instruct your agent to avoid using angle brackets or path-like strings in its final response. Add this to your agent's system prompt:
# Add to System Prompt
"When responding, never use angle brackets like <audio> or <file> to describe actions. Simply use plain text."
Quick Fix: Clear Session History
If the error persists because the "bad string" is stuck in the conversation history (causing repeated crashes during log replay), clear the session.
/clear
Success Check
After clearing the session or updating, try asking the agent to "describe an audio file". If it responds without crashing the gateway, the regex conflict is resolved.
Did this guide solve your problem?