Telegram/Discord: honor outbound mediaMaxMb uploads by vincentkoc · Pull Request #38065 · openclaw/openclaw

vincentkoc · 2026-03-06T15:51:47Z

Summary

Problem: Telegram outbound uploads were not honoring channels.telegram.mediaMaxMb, so some uploads still fell back to MIME-based limits from the shared media pipeline, including 16MB audio/video caps.
Why it matters: Telegram should default to a much higher upload ceiling, and operators need a real config knob they can tune instead of hidden fallback behavior.
What changed: Telegram outbound sends now use channels.telegram.mediaMaxMb with a default of 100MB; Discord outbound uploads now also honor channels.discord.mediaMaxMb; docs, tests, and changelog were updated.
What did NOT change (scope boundary): Slack and Signal behavior were not changed because they were already wiring channel media caps correctly.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

None.

User-visible / Behavior Changes

channels.telegram.mediaMaxMb now applies to outbound Telegram uploads, not just inbound media handling.
Telegram now defaults to 100MB for media cap when unset.
channels.discord.mediaMaxMb now applies consistently to outbound Discord uploads too.

Security Impact (required)

New permissions/capabilities? (Yes/No): No
Secrets/tokens handling changed? (Yes/No): No
New/changed network calls? (Yes/No): No
Command/tool execution surface changed? (Yes/No): No
Data access scope changed? (Yes/No): No
If any Yes, explain risk + mitigation:

Repro + Verification

Environment

OS: macOS
Runtime/container: local Node/pnpm workspace
Model/provider: N/A
Integration/channel (if any): Telegram, Discord
Relevant config (redacted): channels.telegram.mediaMaxMb, channels.discord.mediaMaxMb

Steps

Configure Telegram or Discord without an explicit outbound media override in the send path.
Send a media attachment through the outbound adapter/helper path.
Observe the resolved loadWebMedia cap used for upload.

Expected

Telegram should use channels.telegram.mediaMaxMb, defaulting to 100MB when unset.
Discord should use channels.discord.mediaMaxMb, defaulting to 8MB when unset.

Actual

Telegram outbound could fall back to MIME defaults, including 16MB for some media kinds.
Discord outbound upload helpers could bypass channels.discord.mediaMaxMb and fall back to shared defaults.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Passing verification:

pnpm vitest run src/telegram/send.test.ts src/discord/send.sends-basic-channel-messages.test.ts
✓ src/discord/send.sends-basic-channel-messages.test.ts
✓ src/telegram/send.test.ts
Tests 82 passed

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: targeted Telegram and Discord outbound media-cap tests; formatting check on touched TS files.
Edge cases checked: Telegram default cap path, Telegram configured cap path, Discord default cap path, Discord configured cap path.
What you did not verify: live Telegram/Discord network sends against real accounts.

Compatibility / Migration

Backward compatible? (Yes/No): Yes
Config/env changes? (Yes/No): No
Migration needed? (Yes/No): No
If yes, exact upgrade steps:

Failure Recovery (if this breaks)

How to disable/revert this change quickly: set an explicit smaller channels.telegram.mediaMaxMb or revert this branch.
Files/config to restore: src/telegram/send.ts, src/telegram/bot.ts, src/discord/send.shared.ts, src/discord/send.outbound.ts
Known bad symptoms reviewers should watch for: unexpected upload-size regressions on Telegram or Discord outbound sends.

Risks and Mitigations

Risk: Raising Telegram's default cap to 100MB could allow larger local/remote media reads than before when operators relied on the implicit fallback.
- Mitigation: channels.telegram.mediaMaxMb remains configurable and now applies consistently to both inbound and outbound paths.

AI-assisted: yes.
Testing: fully tested for the targeted unit coverage above.

aisle-research-bot · 2026-03-06T15:53:05Z

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

#	Severity	Title
1	🔵 Low	Discord outbound media cap bypass via non-finite mediaMaxMb (Infinity) leading to unbounded downloads

1. 🔵 Discord outbound media cap bypass via non-finite mediaMaxMb (Infinity) leading to unbounded downloads

Property	Value
Severity	Low
CWE	CWE-400
Location	`src/discord/send.outbound.ts:148-151`

Description

sendMessageDiscord() computes a byte cap from accountInfo.config.mediaMaxMb using only a typeof === "number" check and then passes it to loadWebMedia().

mediaMaxMb is config-controlled and schema-validated as z.number().positive().optional() (no .finite() / upper bound).
In JSON5, Infinity is a valid numeric literal; Infinity passes positive().
Infinity * 1024 * 1024 remains Infinity, which is then used as maxBytes.
In loadWebMedia()/fetchRemoteMedia(), maxBytes=Infinity effectively disables the size limit:
- readResponseWithLimit() compares total > maxBytes; with Infinity this never trips
- the whole response is buffered into memory, enabling bandwidth/memory exhaustion (DoS)

Vulnerable code:

const mediaMaxBytes =
  typeof accountInfo.config.mediaMaxMb === "number"
    ? accountInfo.config.mediaMaxMb * 1024 * 1024
    : 8 * 1024 * 1024;

Enforcement that becomes ineffective with Infinity:

src/web/media.ts: fetchCap = Math.max(maxBytes, defaultFetchCap) (=> Infinity)
src/media/fetch.ts: readResponseWithLimit(res, maxBytes) with maxBytes=Infinity
src/media/read-response-with-limit.ts: if (total > maxBytes) ... (never true for Infinity)

Recommendation

Validate and clamp media caps to finite safe bounds before converting to bytes, and/or enforce this at config schema level.

Schema hardening (recommended):

// example: require finite, positive, and a sane upper bound
mediaMaxMb: z.number().finite().positive().max(500).optional();

Runtime hardening (defense-in-depth):

const mb = accountInfo.config.mediaMaxMb;
const mediaMaxBytes =
  Number.isFinite(mb) && mb > 0
    ? Math.min(mb, 500) * 1024 * 1024
    : 8 * 1024 * 1024;

Also consider validating inside loadWebMedia/fetchRemoteMedia:

reject non-finite maxBytes
treat maxBytes <= 0 as invalid rather than disabling limits

Analyzed PR: #38065 at commit 67917e9

_{Last updated on: 2026-03-06T16:42:07Z}

greptile-apps · 2026-03-06T15:55:27Z

Greptile Summary

This PR fixes outbound media upload caps for both Telegram and Discord: Telegram's sendMessageTelegram now reads channels.telegram.mediaMaxMb (defaulting to 100 MB) instead of relying on MIME-based fallback limits, and Discord's sendMessageDiscord now passes channels.discord.mediaMaxMb (defaulting to 8 MB) through to sendDiscordMedia. The bot.ts inbound default is also raised from 5 MB to 100 MB for consistency.

src/telegram/send.ts: mediaMaxBytes is now derived from opts.maxBytes (caller override) or account.config.mediaMaxMb, defaulting to 100 MB — correct operator precedence and clean fallback chain.
src/telegram/bot.ts: default fallback raised from 5 → 100 to match the send path.
src/discord/send.outbound.ts / send.shared.ts: mediaMaxBytes threaded from config through sendDiscordMedia, fixing both the regular-message and forum-thread media paths.
Tests added for default and configured caps on both channels.
One gap: the materializeVoiceMessageInput helper in send.outbound.ts still uses the hardcoded maxBytesForKind("audio") (16 MB) cap, so Discord voice-message uploads remain outside the new mediaMaxMb control even after this PR.

Confidence Score: 4/5

Safe to merge; the fix is well-scoped and the targeted tests pass, with one minor inconsistency in the Discord voice-message path left unaddressed.
The logic changes are small and focused, operator precedence in the Telegram expression is correct, both default and configured paths are covered by new unit tests, and docs/changelog are updated. Score is 4 rather than 5 solely because materializeVoiceMessageInput still bypasses mediaMaxMb for Discord voice messages, creating a visible inconsistency within the same outbound path this PR claims to fix.
src/discord/send.outbound.ts — materializeVoiceMessageInput at line 488 still uses a hardcoded 16 MB audio cap instead of mediaMaxMb.

Comments Outside Diff (1)

src/discord/send.outbound.ts, line 488 (link)

Voice message path still ignores mediaMaxMb

materializeVoiceMessageInput uses the hardcoded maxBytesForKind("audio") cap (16 MB) rather than the mediaMaxMb that this PR propagates everywhere else in the outbound Discord path. This means a Discord bot configured with channels.discord.mediaMaxMb: 50 will still silently cap voice-message source files at 16 MB, which contradicts the documented behaviour introduced by this PR.

Consider accepting a maxBytes parameter here and threading mediaMaxBytes through the call-site (similar to how sendDiscordMedia was updated):
```
async function materializeVoiceMessageInput(
  mediaUrl: string,
  maxBytes: number,
): Promise<{ filePath: string }> {
  const media = await loadWebMediaRaw(mediaUrl, maxBytes);
```

_{Last reviewed commit: 67917e9}

* main: Mattermost: harden interaction callback binding (openclaw#38057) WhatsApp: honor outbound mediaMaxMb (openclaw#38097) openai-image-gen: validate --background and --style options (openclaw#36762) Docs: align BlueBubbles media cap wording Telegram/Discord: honor outbound mediaMaxMb uploads (openclaw#38065) CI: run changed-scope on main pushes Skills/nano-banana-pro: clarify MEDIA token comment (openclaw#38063) nano-banana-pro: respect explicit --resolution when editing images (openclaw#36880) CI: drop unused install-smoke bootstrap fix(nano-banana-pro): remove space after MEDIA: token in generate_image.py (openclaw#18706) docs: context engine docs(config): list the context engine plugin slot docs(plugins): add context-engine manifest kind example docs(plugins): document context engine slots and registration docs(protocol): document slash-delimited schema lookup plugin ids docs(tools): document slash-delimited config schema lookup paths fix(session): tighten direct-session webchat routing matching (openclaw#37867) feature(context): extend plugin system to support custom context management (openclaw#22201) Gateway: allow slash-delimited schema lookup paths

* Telegram: default media cap to 100MB * Telegram: honor outbound mediaMaxMb * Discord: add shared media upload cap * Discord: pass mediaMaxMb to outbound sends * Telegram: cover outbound media cap sends * Discord: cover media upload cap config * Docs: update Telegram media cap guide * Docs: update Telegram config reference * Changelog: note media upload cap fix * Docs: note Discord upload cap behavior

* Telegram: default media cap to 100MB * Telegram: honor outbound mediaMaxMb * Discord: add shared media upload cap * Discord: pass mediaMaxMb to outbound sends * Telegram: cover outbound media cap sends * Discord: cover media upload cap config * Docs: update Telegram media cap guide * Docs: update Telegram config reference * Changelog: note media upload cap fix * Docs: note Discord upload cap behavior (cherry picked from commit 9c1786b)

vincentkoc added 9 commits March 6, 2026 10:50

Telegram: default media cap to 100MB

69563fa

Telegram: honor outbound mediaMaxMb

0bba818

Discord: add shared media upload cap

72e8325

Discord: pass mediaMaxMb to outbound sends

cf67d73

Telegram: cover outbound media cap sends

a901b47

Discord: cover media upload cap config

1248cb6

Docs: update Telegram media cap guide

ade97ef

Docs: update Telegram config reference

4065df1

Changelog: note media upload cap fix

fbd3e86

vincentkoc self-assigned this Mar 6, 2026

openclaw-barnacle bot added docs Improvements or additions to documentation channel: discord Channel integration: discord channel: telegram Channel integration: telegram gateway Gateway runtime size: S maintainer Maintainer-authored PR labels Mar 6, 2026

Docs: note Discord upload cap behavior

8aafc34

vincentkoc marked this pull request as ready for review March 6, 2026 15:52

Merge branch 'main' into vincentkoc-code/telegram-media-max-config

67917e9

vincentkoc merged commit 9c1786b into main Mar 6, 2026
9 checks passed

vincentkoc deleted the vincentkoc-code/telegram-media-max-config branch March 6, 2026 15:53

vincentkoc mentioned this pull request Mar 6, 2026

WhatsApp: honor outbound mediaMaxMb #38097

Merged

18 tasks

github-actions bot mentioned this pull request Mar 6, 2026

📡 Upstream Digest — 2026-03-06 16:31 UTC curtismercier/openclaw-mods#193

Open

alexyyyander mentioned this pull request Mar 7, 2026

fix/gateway token mismatch 38617 #38676

Closed

alexey-pelykh mentioned this pull request Mar 10, 2026

Cherry-pick: Telegram DM draft clear, mediaMaxMb, retry narrowing remoteclaw/remoteclaw#838

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Telegram/Discord: honor outbound mediaMaxMb uploads#38065

Telegram/Discord: honor outbound mediaMaxMb uploads#38065
vincentkoc merged 11 commits intomainfrom
vincentkoc-code/telegram-media-max-config

vincentkoc commented Mar 6, 2026

Uh oh!

aisle-research-bot bot commented Mar 6, 2026 •

edited

Loading

Uh oh!

Uh oh!

greptile-apps bot commented Mar 6, 2026 •

edited

Loading

Comments Outside Diff (1)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

vincentkoc commented Mar 6, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Uh oh!

aisle-research-bot bot commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Aisle Security Analysis

1. 🔵 Discord outbound media cap bypass via non-finite mediaMaxMb (Infinity) leading to unbounded downloads

Description

Recommendation

Uh oh!

Uh oh!

greptile-apps bot commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 4/5

Comments Outside Diff (1)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

aisle-research-bot bot commented Mar 6, 2026 •

edited

Loading

greptile-apps bot commented Mar 6, 2026 •

edited

Loading