Summary
The �gents/tool-images resizer correctly downsizes images on fresh upload (e.g. 1.28MB → 29.6KB), but when an embedded agent run is started with a long conversation history, previously-processed images appear to be re-injected from their stored (original) form rather than re-passing through the resizer. This causes an invalid_request_error from the LLM provider when the raw image exceeds 5MB.
Reproduction
- Start a session and upload several large screenshots (3440×1440px). Resizer fires correctly, logs show e.g. Image resized to fit limits: 3440x1440px 1.28MB -> 29.6KB (-97.7%)
- Continue the session until context is deep (100+ messages)
- Session compaction fires, or a new embedded agent run is started that replays the full message history
- Embedded agent run fails with:
LLM request rejected: messages.138.content.1.image.source.base64: image exceeds 5 MB maximum: 6475700 bytes > 5242880 bytes
Expected behavior
Images should pass through the resizer on context replay / re-injection, not just on initial upload. The stored message representation should either use the already-resized form, or the resize step should be applied whenever images are injected into a model request regardless of origin.
Actual behavior
Images stored in message history are re-injected at their original byte size on replay, bypassing the resize pipeline and hitting the provider's 5MB hard limit.
Environment
- OpenClaw: 2026.3.22 (with control-ui backported from 2026.3.13)
- Provider: anthropic/claude-sonnet-4-6
- Surface: webchat embedded agent run
- Image dimensions: 3440×1440px
- Failing message index: 138 (deep context)
Suggested fix
Apply the ool-images resize pipeline at the point where images are serialized into the model request payload, not only at upload time. Alternatively, store the resized bytes in the message record rather than a reference to the original.
Summary
The �gents/tool-images resizer correctly downsizes images on fresh upload (e.g. 1.28MB → 29.6KB), but when an embedded agent run is started with a long conversation history, previously-processed images appear to be re-injected from their stored (original) form rather than re-passing through the resizer. This causes an invalid_request_error from the LLM provider when the raw image exceeds 5MB.
Reproduction
LLM request rejected: messages.138.content.1.image.source.base64: image exceeds 5 MB maximum: 6475700 bytes > 5242880 bytesExpected behavior
Images should pass through the resizer on context replay / re-injection, not just on initial upload. The stored message representation should either use the already-resized form, or the resize step should be applied whenever images are injected into a model request regardless of origin.
Actual behavior
Images stored in message history are re-injected at their original byte size on replay, bypassing the resize pipeline and hitting the provider's 5MB hard limit.
Environment
Suggested fix
Apply the ool-images resize pipeline at the point where images are serialized into the model request payload, not only at upload time. Alternatively, store the resized bytes in the message record rather than a reference to the original.