Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Hardcoded 5MB media store limit blocks generated/outbound media before configured channel limits apply [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#66229•Fetched 2026-04-14 05:38:45
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
vbrisanvbrisan
Participants
neeravmakwananeeravmakwanavbrisanvbrisan
Timeline (top)
commented ×1cross-referenced ×1

OpenClaw appears to enforce a hardcoded 5MB media store/staging limit before channel or agent-level media limits can apply.

In the installed runtime bundle, the hardcoded limit is in:

  • dist/store-CA7OW_2w.js

with:

const MEDIA_MAX_BYTES = 5 * 1024 * 1024;

This caused a generated video to fail with:

Media exceeds 5MB limit

Even though media delivery and channel/media configuration suggest larger payloads may be supported downstream.

Error Message

  • or the error should clearly explain that a separate hard global staging limit is being enforced Observed runtime error:

Root Cause

Observed while generating video output. This is not specific to a single model provider, because the failure appears to occur in OpenClaw's own media store/staging layer.

Fix Action

Fix / Workaround

It would be helpful if this were fixed by one of these approaches:

PR fix notes

PR #66240: fix(media): honor configured store limits

Description (problem / solution / changelog)

Summary

  • Problem: generated media saves and volatile outbound reply-media persistence still fell back to the media store's hardcoded 5 MB default before configured agent media limits could apply.
  • Why it matters: video, audio, and image outputs could fail early with Media exceeds 5MB limit even when the operator had already raised agents.defaults.mediaMaxMb.
  • What changed: added a shared helper for resolving configured agent media limits, threaded that limit into generated media saves and outbound reply-media persistence, and let saveMediaSource() honor an explicit max-byte override instead of always enforcing 5 MB.
  • What did NOT change (scope boundary): this PR does not change channel-specific limit resolution or widen unrelated inbound staging paths.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #66229
  • Related #66229
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: saveMediaBuffer() and saveMediaSource() defaulted to MEDIA_MAX_BYTES = 5 * 1024 * 1024, and generated-media call sites plus reply-media persistence were passing no override.
  • Missing detection / guardrail: nearby tests locked in the default 5 MB ceiling, but there was no regression coverage proving configured agent media limits were threaded through these save paths.
  • Contributing context (if known): outbound URL-based attachment flows already pass an explicit maxBytes, so the mismatch was limited to generated buffers and persisted local reply media.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/media/store.test.ts, src/agents/tools/image-generate-tool.test.ts, src/agents/tools/video-generate-tool.test.ts, src/agents/tools/music-generate-tool.test.ts, src/auto-reply/reply/reply-media-paths.test.ts
  • Scenario the test should lock in: configured agents.defaults.mediaMaxMb is passed into generated media saves and volatile outbound reply-media persistence instead of falling back to the store default.
  • Why this is the smallest reliable guardrail: the bug happens before channel delivery, so the smallest stable guardrail is to assert the exact store call arguments and store-layer override behavior.
  • Existing test that already covers this (if any): the existing store and generation tests covered the save paths, but not the configured-limit wiring.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • Generated image, video, and music outputs now respect agents.defaults.mediaMaxMb when OpenClaw saves them into managed media storage.
  • Volatile reply media persisted into managed outbound media now uses the same configured agent limit instead of the hardcoded 5 MB default.
  • The store's explicit size-limit error now reflects the effective limit instead of always reporting 5 MB.

Diagram (if applicable)

Before:
[generated media or volatile reply-media path] -> saveMediaBuffer/saveMediaSource default 5 MB -> early failure

After:
[generated media or volatile reply-media path] -> resolve configured agent media limit -> save with effective maxBytes -> downstream delivery can proceed

Security Impact (required)

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

Repro + Verification

Environment

  • OS: macOS 15.5 host
  • Runtime/container: local repo checkout
  • Model/provider: N/A
  • Integration/channel (if any): generated media / reply-media persistence
  • Relevant config (redacted): agents.defaults.mediaMaxMb: 8

Steps

  1. Configure agents.defaults.mediaMaxMb above 5 MB.
  2. Generate image, video, or music output larger than 5 MB, or persist a volatile local reply-media path into managed outbound media.
  3. Observe whether the save path still fails before downstream delivery sees the media.

Expected

  • Managed media saves honor the configured agent media limit instead of hard-failing at 5 MB.

Actual

  • Before this PR, the store-layer save path defaulted to 5 MB and could fail with Media exceeds 5MB limit.

Evidence

Attach at least one:

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

Human Verification (required)

  • Verified scenarios: ran the focused regression tests for store override behavior, generated image/video/music save paths, and outbound reply-media persistence; also ran pnpm check and pnpm build.
  • Edge cases checked: the default 5 MB store behavior still remains when no configured override is present.
  • What you did not verify: full pnpm test suite and a live end-to-end channel send with a >5 MB generated asset.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

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

Risks and Mitigations

  • Risk: the configured agent media limit could now allow larger managed-media saves than before on these paths.
    • Mitigation: the change only applies when the operator has explicitly set agents.defaults.mediaMaxMb; the 5 MB default remains unchanged otherwise.

Additional Notes

  • AI assistance: yes.
  • Testing level: targeted tests plus pnpm check and pnpm build.

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/tools/image-generate-tool.test.ts (modified, +4/-2)
  • src/agents/tools/image-generate-tool.ts (modified, +4/-10)
  • src/agents/tools/music-generate-tool.test.ts (modified, +9/-1)
  • src/agents/tools/music-generate-tool.ts (modified, +3/-1)
  • src/agents/tools/video-generate-tool.test.ts (modified, +9/-1)
  • src/agents/tools/video-generate-tool.ts (modified, +3/-1)
  • src/auto-reply/reply/reply-media-paths.test.ts (modified, +3/-2)
  • src/auto-reply/reply/reply-media-paths.ts (modified, +3/-1)
  • src/media/configured-max-bytes.ts (added, +11/-0)
  • src/media/store.test.ts (modified, +31/-0)
  • src/media/store.ts (modified, +22/-11)

Code Example

const MEDIA_MAX_BYTES = 5 * 1024 * 1024;

---

Media exceeds 5MB limit

---

const MEDIA_MAX_BYTES = 5 * 1024 * 1024;
RAW_BUFFERClick to expand / collapse

Bug type

Incorrect behavior

Summary

OpenClaw appears to enforce a hardcoded 5MB media store/staging limit before channel or agent-level media limits can apply.

In the installed runtime bundle, the hardcoded limit is in:

  • dist/store-CA7OW_2w.js

with:

const MEDIA_MAX_BYTES = 5 * 1024 * 1024;

This caused a generated video to fail with:

Media exceeds 5MB limit

Even though media delivery and channel/media configuration suggest larger payloads may be supported downstream.

Steps to reproduce

  1. Configure or use a workflow that generates media larger than 5MB, for example a generated video.
  2. Ensure the downstream channel or agent config would otherwise allow larger media.
  3. Attempt to return or stage that media through the normal OpenClaw media/tool pipeline.

Expected behavior

One of the following should happen:

  • the effective media limit should be derived from channel/agent config
  • the store/staging layer should have its own documented config knob
  • or the error should clearly explain that a separate hard global staging limit is being enforced

Configured media size allowances should not be silently undermined by a lower hardcoded cap earlier in the pipeline.

Actual behavior

Media fails early with:

Media exceeds 5MB limit

This appears to happen in the media store/runtime layer before downstream configured media limits can be meaningfully applied.

OpenClaw version

2026.4.11

Operating system

Ubuntu 24.04

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

OpenClaw media tool pipeline

Config file / key location

Not config-specific. Observed in the installed runtime bundle:

  • dist/store-CA7OW_2w.js

Additional provider/model setup details

Observed while generating video output. This is not specific to a single model provider, because the failure appears to occur in OpenClaw's own media store/staging layer.

Logs, screenshots, and evidence

Observed runtime error:

Media exceeds 5MB limit

Relevant installed runtime snippet:

const MEDIA_MAX_BYTES = 5 * 1024 * 1024;

Also observed that OpenClaw has other media limit resolution paths, including configurable channel/agent media max byte logic, which suggests this 5MB cap is an earlier hard ceiling rather than the only intended effective limit.

Impact and severity

This blocks generated or staged media workflows, especially video, and makes higher configured media limits ineffective or misleading.

Additional information

It would be helpful if this were fixed by one of these approaches:

  1. make the staging/store media limit configurable
  2. derive it from effective channel/agent media limits
  3. document it clearly as a separate hard cap and surface that in config/docs

extent analysis

TL;DR

The most likely fix is to modify the hardcoded MEDIA_MAX_BYTES limit in the OpenClaw media store/runtime layer to be configurable or derived from channel/agent media limits.

Guidance

  • Identify the dist/store-CA7OW_2w.js file in the installed runtime bundle and locate the MEDIA_MAX_BYTES constant to understand the current hardcoded limit.
  • Consider modifying this value to a higher limit or making it configurable to allow for larger media payloads.
  • Review the OpenClaw documentation and configuration options to see if there are any existing settings that can be used to override or configure the media limit.
  • Test the media workflow with a smaller payload to verify that the issue is indeed related to the hardcoded limit.

Example

// Potential modification to make MEDIA_MAX_BYTES configurable
const MEDIA_MAX_BYTES = process.env.MEDIA_MAX_BYTES || 5 * 1024 * 1024;

Notes

The fix may require changes to the OpenClaw codebase or configuration, and it is unclear if this is a known issue or a customization requirement. The provided example is a potential solution, but it may not be the only or best approach.

Recommendation

Apply a workaround by modifying the MEDIA_MAX_BYTES limit to a higher value or making it configurable, as this will allow for larger media payloads and prevent the hardcoded limit from being enforced.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

One of the following should happen:

  • the effective media limit should be derived from channel/agent config
  • the store/staging layer should have its own documented config knob
  • or the error should clearly explain that a separate hard global staging limit is being enforced

Configured media size allowances should not be silently undermined by a lower hardcoded cap earlier in the pipeline.

#callback error#memory management#API rate limit#retriever error#runtime error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Hardcoded 5MB media store limit blocks generated/outbound media before configured channel limits apply [1 pull requests, 1 comments, 2 participants]