[BUG] Telegram voice/media download fails intermittently in Docker (missing autoSelectFamily)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Telegram voice messages (and likely other media) intermittently fail to download inside Docker containers with:

MediaFetchError: Failed to fetch media from https://api.telegram.org/file/bot<token>/voice/file_5.oga: TypeError: fetch failed

The failure is intermittent — sometimes it works, sometimes it doesn't, within the same session.

Root Cause Analysis

The Telegram media download path in reply-BwvhooPB.js uses globalThis.fetch:

const fetchImpl = proxyFetch ?? globalThis.fetch;
const saved = await downloadAndSaveTelegramFile(file.file_path, fetchImpl);

This raw fetch lacks autoSelectFamily: true, which was added to the SSRF pinned dispatcher in PR #19950 to fix a similar IPv6-related issue (#19147) for image uploads.

In Docker environments where IPv6 DNS resolves but IPv6 routing is unavailable, Node.js fetch may attempt IPv6 first and fail. The SSRF dispatcher handles this correctly with autoSelectFamily: true + autoSelectFamilyAttemptTimeout: 300, but the media download code path bypasses the SSRF dispatcher entirely.

Evidence

From the detailed log file inside the container:

{
  "module": "telegram-auto-reply",
  "chatId": 8565338793,
  "error": "MediaFetchError: Failed to fetch media from https://api.telegram.org/file/bot<token>/voice/file_5.oga: TypeError: fetch failed"
}

DNS resolution inside the container returns both IPv4 and IPv6:

IPv4: [ '149.154.166.110' ]
IPv6: [ '2001:67c:4e8:f004::9' ]

Manual fetch() from inside the container works (likely because it happened to use IPv4 that time), confirming the issue is intermittent and timing-dependent.

What Should Happen?

Media downloads should use autoSelectFamily: true (or go through the SSRF pinned dispatcher) so that when IPv6 fails, it automatically falls back to IPv4 — just like the fix in PR #19950.

Suggested Fix

Pass autoSelectFamily: true to the fetch call in downloadAndSaveTelegramFile, or use the SSRF dispatcher for Telegram file downloads. This would make the behavior consistent with the fix already applied in #19950.

Steps to Reproduce

1. Run OpenClaw in Docker on a host where IPv6 DNS resolves but IPv6 routing is unavailable (common in Docker default bridge networks)
2. Send voice messages to a Telegram bot
3. Observe intermittent "Failed to download media" errors

Claude Model

Opus

Is this a regression?

No, this code path was never covered by the #19950 fix

Claude Code Version

2026.2.23 (locally built from source)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux (Docker container on WSL2)

Terminal/Shell

N/A (Telegram bot)

Additional Information

• Related: #19147 (original IPv6/SSRF issue), PR #19950 (partial fix for SSRF dispatcher only)
• Related: #22187 (audio transcription lacks diagnostic logging — makes this harder to debug)
• The dnsResultOrder=ipv4first setting shown in Telegram provider logs does not appear to affect the media fetch code path
• Environment: Docker default bridge network, host has IPv6 DNS but no IPv6 routing