openclaw - 💡(How to fix) Fix [Bug]: Telegram outbound local media still buffers whole local files into RAM outside the Local Bot API loopback fast-path

Bug type

Performance / memory usage

Summary

Telegram outbound delivery in OpenClaw still appears to load whole local media files into RAM in common local-file send paths, instead of preserving a disk-backed path/stream all the way through send time.

This matters because large Telegram uploads can already succeed above 100MB, but on smaller hosts the practical limit becomes available RAM rather than Telegram's file ceiling.

There is already related work in this area:

• #45720 added Local Bot API support and explicitly noted that outbound local media paths can stay as file references for loopback Local Bot API roots instead of always being fully buffered first.
• #85219 improved Telegram attachment path handling.
• #46023 fixed mediaMaxMb propagation for final replies.

However, the broader problem still seems open outside that narrow Local Bot API loopback optimization: local outbound media can still end up buffered into memory before send.

Steps to reproduce

1. Run OpenClaw on a low-memory Linux host (for example an LXC/container with ~4GB RAM).
2. Configure Telegram outbound sending with allowed local media roots.
3. Use a local file send flow such as path, filePath, attachments, or another Telegram outbound local-media path.
4. Send a relatively large local file (for example ~200MB; larger files make the memory effect easier to see).
5. Observe gateway process memory during the outbound send and compare it to the expected on-disk streaming/reference behavior.

Expected behavior

When Telegram receives a valid approved local file path and no preprocessing is required, OpenClaw should preserve a disk-backed file reference or stream where possible, instead of eagerly building a full in-memory buffer.

Actual behavior

Related code paths and prior investigation still point to buffer-based handling (for example media.buffer) in common outbound local-media flows, so RAM becomes the practical bottleneck for large sends even when Telegram itself would accept the file size.

Additional information

Relevant context:

• Telegram channel
• local media roots allowed
• self-hosted Linux container/LXC
• Local Bot API support already added in #45720, including a loopback fast-path that preserves local references in a narrower case
• this issue is about the broader remaining local outbound path outside that narrow optimization

Observed practical impact in our environment: files above 100MB can already succeed, but a 4GB host is still exposed to RAM pressure before reaching Telegram's true upload ceiling.

Affected: self-hosted Telegram users sending large local files Severity: Medium-High for small hosts or containers Frequency: consistent design limitation rather than a one-off flake Consequence: large local sends are constrained by RAM and can become risky or fail earlier than necessary

Regression window: not yet confirmed as a narrow recent regression. This looks more like a remaining architectural limitation that is still observable on recent 2026.x builds after the final-reply mediaMaxMb fix (#46023).

Written by AI under human direction.