OpenClaw Bug: Pasting Images in Control UI Can Dump Massive Base64 Text into the Composer

A new community issue reports that pasting an image into the OpenClaw Control UI composer can sometimes inject a huge inline data:image/...;base64,... string as plain text instead of turning the paste into an attachment.

That is not just ugly UX. It also creates a practical operations problem:

• the composer becomes hard to recover cleanly
• failed sends become harder to reason about
• emergency hotfixes are risky if you only have an installed dist bundle with hashed UI assets

The issue becomes more confusing because the report also found that draft restoration on failed send may already exist deeper in the send pipeline. In other words, if you patch the wrong layer, you can easily make recovery logic worse instead of better.

• Source issue: openclaw/openclaw#62604

TL;DR

If image paste in the Control UI turns into a giant base64 blob in the message box:

1. Treat it first as a Control UI paste-handling bug, not as user error.
2. Avoid trying to “fix” it by quickly editing a button click wrapper in a compiled bundle.
3. Check whether your install is a global npm / dist-first package where only hashed assets are available.
4. Use safer short-term mitigations until upstream clarifies the fix.
5. If you operate shared environments, document the symptom so teammates do not mistake it for a provider or model problem.

What the bug looks like

According to the issue report, the broken path is straightforward:

• open the OpenClaw Control UI composer
• copy an image to the clipboard
• paste it into the composer
• instead of getting an attachment, the composer may receive a very large inline data:image/...;base64,... string as plain text

The report says the problem became easier to notice while testing smaller local vision models, even though it was not obvious when using some Anthropic API flows.

That matters because many teams only discover this class of problem after changing models or testing a lower-level local workflow.

Why this is operationally worse than a normal UI glitch

A plain UI glitch is annoying. This one is more expensive.

If a massive base64 payload lands directly in the composer:

• users may accidentally send garbage instead of an image
• the draft becomes noisy and harder to inspect
• the message state can be harder to restore safely after failure
• responders may patch the wrong layer under pressure

The issue report adds an important second observation: on failed sends, draft and attachment restoration may already happen deeper in the send pipeline using preserved previous state.

That means a quick “just wrap onSend() differently” patch in the UI layer may be the wrong fix, because recovery ownership may already live elsewhere.

Why installed packages make this harder to patch safely

The reporter was investigating a locally installed OpenClaw package under a global npm path and found that the package exposed compiled hashed Control UI assets, not a normal editable source tree for UI repair.

In practice, that means local emergency patching can turn fragile fast:

• you may need to edit dist/control-ui/assets/index-*.js
• the bundle is minified
• the filename is hashed
• small mistakes are hard to validate and easy to lose later

This does not mean the root bug is “missing assets” in the same way as older packaging regressions. It means the current bug is harder to hotfix safely when your installation only exposes dist artifacts.

How to confirm you are hitting this exact issue

Use this sequence so you do not mix it up with a model failure or an attachment upload problem.

1) Reproduce with a clipboard image paste

Try the simplest path first:

1. open the Control UI
2. copy an image to the clipboard
3. paste into the composer

If the composer fills with a long data:image/...;base64,... payload instead of creating an image attachment, your symptom matches the report.

2) Check whether the problem is specifically in the paste path

The issue is about clipboard image paste, not necessarily all attachment flows.

So before escalating, compare:

• clipboard paste behavior
• normal file attachment behavior, if your install supports it

If file attachments behave normally while paste is broken, the bug is more likely isolated to paste handling rather than a general upload pipeline failure.

3) Confirm what kind of installation you are debugging

If your OpenClaw install comes from a global npm package or another dist-first artifact, local patching is riskier because you may not have a normal source tree.

That is important context for incident response. It tells your team whether you should:

• stop at a workaround
• switch versions
• move to a source-based fix path
• wait for upstream clarification instead of editing minified assets

Lowest-risk mitigations right now

Mitigation A: Stop relying on clipboard image paste in affected environments

If this bug is easy to reproduce in your install, the safest immediate mitigation is simple:

• do not paste images directly into the composer
• use alternative attachment methods if available
• keep image input workflows out of unattended or business-critical paths

This is boring advice, but it avoids turning one UI bug into corrupted drafts or bad downstream prompts.

Mitigation B: Do not hot-patch send recovery logic at the button layer unless you have source-level confidence

The issue explicitly notes that failed-send restoration seems to already exist deeper in the send pipeline.

That means a fast local patch at the button layer can create a second-order bug, such as:

• duplicate restore behavior
• mismatched draft state
• attachments restored in one path but not another

If you are debugging from compiled assets only, resist the temptation to patch first and reason later.

Mitigation C: Treat dist-bundle patching as a last resort, not a default response

If your only editable files are hashed/minified assets inside an installed package, use extreme caution.

That path may be acceptable for a one-off internal emergency, but it is a poor default because:

• the patch is hard to review
• future upgrades will overwrite it
• reproducing the exact change later is painful
• it is easy to fix the symptom while breaking the send pipeline contract

What upstream likely needs to clarify or fix

Based on the report, maintainers will likely need to inspect at least four things:

• how clipboard image data is parsed in the Control UI paste path
• whether pasted data:image/...;base64 content is incorrectly treated as plain text input
• where failed-send draft restoration is supposed to live
• whether installed distributions should expose better debugging traceability for UI incidents

The issue also suggests a good regression-test direction:

• pasted image handling in the composer
• failed send restoring both draft text and attachments

When to consider the problem actually fixed

Do not call it fixed just because the UI no longer crashes. Re-test the symptom itself:

• pasting an image creates an attachment or is rejected cleanly
• the composer no longer fills with giant base64 text
• failed sends still restore the correct draft state
• attachment recovery behaves consistently after an error

If you arrived from the homepage, install guide, or migration guide

GA4 now places this image-paste bug page inside the same small Chinese discovery cluster. First confirm that the failure is really Control UI image paste turning into a massive base64 blob in the composer, not an install, migration, or CLI-latency issue.

• The UI opens, but pasting a screenshot floods the input box with long text: stay on this page and capture browser, image size, paste path, and whether the clipboard compressed the image.
• OpenClaw was just installed and Web UI or Gateway is not healthy yet: use the Mac install guide or installation success checklist before treating this as a paste bug.
• A Moltbot migration left paths, commands, or old config confusing: use the 1-minute migration guide, then reproduce image paste again.

This split reduces false positives: installation and migration issues get cleared first, while real Control UI image-paste pollution stays on this page.

If troubleshooting traffic brings you here, separate paste corruption from model or upload failure

This page now appears in the same GA4 window as setup, troubleshooting, and other operator bug pages. Treat that as a high-intent recovery path: the reader may only know that “image input broke,” not whether the failure is in upload handling, composer paste handling, or the downstream model call.

Use this split before changing UI code or provider settings:

1. The image never becomes a file or preview: start with browser permissions, upload limits, and storage/API upload handling. The base64 composer bug may not be the first failure.
2. The composer fills with a huge data:image/...base64 string: stop submitting immediately, preserve the payload size and browser path, then use this article’s mitigations.
3. The image preview works but the model call fails: route to provider-key or model-capability troubleshooting instead of patching the paste path.

That routing keeps the article useful for operators arriving from broad troubleshooting searches and helps them avoid fixing the wrong layer.

FAQ for triage and search intent

If the composer is already filled with a massive base64 blob, what should operators do first?

The first move is not to keep clicking send. Treat it as a paste-path failure scene and preserve the signal.

A safer order is:

1. stop editing that draft further
2. record that this was “image paste turned into base64 text”, not a normal long prompt
3. then decide whether to clear the draft, reopen the composer, or switch to an attachment workaround

If people keep editing on top of the blob, it becomes much harder to tell whether the original failure was in paste handling, send behavior, or draft restoration.

When should this be blamed on paste handling rather than the model or provider?

If the failure appears only when users paste an image, while normal text input, ordinary sends, or even file attachments still work, the safer assumption is a Control UI paste-handling bug.

The most expensive mistake at that point is widening the blame surface toward the model, provider, or token limits before proving the paste path is not the real trigger.

If someone searches for data:image base64 pasted into composer, what are the first three branches this page should help them split?

Help them separate these first:

1. whether only clipboard paste is broken or all attachment methods are broken
2. whether they are debugging a source install or a dist-bundle-only install
3. whether failed-send draft restoration also behaves incorrectly

Those three splits are the fastest way to decide between a low-risk workaround and a deeper send-pipeline investigation.

How can operators quickly distinguish accidental huge-base64 paste from a model or provider failure?

Start from what changed first.

This is much more likely a paste-path bug when:

• the bad behavior begins exactly after an image paste action
• the composer fills with data:image/...;base64,... before any model call succeeds or fails
• plain text prompts still send normally
• file attachments or non-paste flows behave differently from clipboard image paste

That sequence makes the Control UI input path the primary suspect. It is a much weaker match for model instability, provider rejection, or token-limit behavior.

What should you verify right after shipping a fix or workaround for image-paste bloat?

Do not stop at “the composer looks cleaner now.”

After any patch or workaround, verify:

1. pasting an image no longer dumps raw base64 text into the composer
2. the intended attachment flow still works, or the UI rejects paste cleanly instead of corrupting the draft
3. normal text sends still behave the same as before
4. failed-send draft restoration still preserves the right text and attachment state
5. the workaround did not quietly break another send path in the compiled UI bundle

That last check matters because this issue sits near send and restore boundaries, where shallow UI fixes can accidentally create a deeper regression.

Evidence checklist before you patch the paste path

Before treating this as a generic composer bug, capture enough detail to separate clipboard handling, attachment routing, and draft restoration:

1. Clipboard source: note whether the image came from a screenshot tool, browser copy, local file preview, or another chat app.
2. Payload shape: record whether the composer receives a visible data:image/...;base64 string, an attachment object, or both.
3. Draft recovery boundary: test whether failed sends reinsert the same corrupted payload after refresh or retry.
4. Installed package version: include the Control UI bundle or OpenClaw version, because packaged UI fixes may lag behind source changes.
5. Safe reproduction asset: keep a small non-sensitive image that reproduces the issue so reviewers do not need private screenshots.

This makes the report actionable for high-intent operators: they can prove whether the bug sits in paste interception, upload conversion, or composer state recovery.

Three-minute judgment after search: clipboard, upload, or draft restore

If you arrived by searching data:image base64 composer, paste image huge text, or “pasting screenshot fills input,” do not change providers or restart Gateway first. Spend three minutes locating which layer is polluting the composer:

1. It only happens on clipboard paste: inspect paste-event interception, clipboard MIME types, and the image-to-attachment conversion path first.
2. Drag-and-drop or file picker uploads also fail: move the investigation to upload APIs, file-size limits, storage permissions, or attachment state instead of only patching the paste handler.
3. The pollution returns after a failed send: focus on draft restore, composer-state serialization, and retry paths so the fix does not only block the first paste.
4. Only the packaged UI reproduces it, while source does not: record the bundle version and build time to confirm whether the packaged UI is behind the source fix.

This routes high-intent image-input traffic to the right repair surface faster: clipboard entry, upload pipeline, draft recovery, or packaged-version drift.

Source

• Community bug report: openclaw/openclaw#62604