Issue with browser screenshots

[unique atlas]

agent things it can send screenshots from browser, but no image comes though.

[fringe flame]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[earnest minnow]

First thing: what does openclaw --version show?

For browser screenshots specifically, the common split is:

• If the agent only took a browser screenshot, that image is available to the agent/tool run, but Discord only gets it if the final reply includes an attachment directive like MEDIA:<path-or-url> on its own line, or the agent uses the message/upload-file path.
• The Discord bot also needs Attach Files permission in that channel/thread. The Discord setup docs list that as part of the baseline bot permissions: https://docs.openclaw.ai/channels/discord
• If the screenshot path is a host-local file://... path outside the agent workspace/sandbox, OpenClaw may drop it during outbound media staging. Workspace-relative paths like ./out/screenshot.png or sandbox-mapped /workspace/... paths are the safer shape.

Useful checks:

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Then ask the agent something very explicit, e.g. “take a browser screenshot and attach it to Discord using MEDIA with the saved screenshot path.” If logs show a media staging/upload error, paste that bit here and we can pin down whether it’s permissions, path mapping, or size/format.

[unique atlas]

im not using a discord bot, im using the webui

the bot responds with "Here's the screenshot of google.com from the headless browser. Everything's working!" but there is no image

[earnest minnow]

Ah, got it — ignore the Discord bot permission bit then.

For the Web UI, screenshots still need to become reply media. The browser tool can capture pixels for the agent, but the UI only renders an attachment when the final assistant message carries media, usually via a standalone line like:

MEDIA:/path/to/screenshot.png

The browser CLI/docs also use that shape; e.g. openclaw browser screenshot prints MEDIA:<path>: https://docs.openclaw.ai/tools/browser

Can you check two things?

openclaw --version
openclaw logs --follow

[earnest minnow]

Then retry in Web UI with something explicit like: “Take a browser screenshot and attach it in your final reply using MEDIA:<saved screenshot path>.”

If it still says it sent it but no image appears, the most likely causes are:

• the final answer didn’t include a MEDIA: line
• the path points somewhere the gateway won’t serve/read
• media prep failed and the log should show the staging/render error

Web UI media behavior is documented here too: https://docs.openclaw.ai/web/control-ui#chat-behavior

[earnest minnow]

That wording means the model is probably claiming success, not actually attaching anything. In Web UI, “here’s the screenshot” is just text unless the final message contains media metadata.

Try forcing it very literally:

Open google.com in the browser. Take a screenshot. In your final answer, include the screenshot as an attachment using a standalone MEDIA:<path> line. Do not just describe it.

If the final visible text still has no image, check whether the raw assistant message / logs mention a MEDIA: path or a media prep error:

openclaw --version
openclaw logs --follow

The expected working path is: browser screenshot saved → assistant final includes MEDIA:/... or mediaUrls → Web UI turns that into an authenticated image block. Docs refs:
https://docs.openclaw.ai/reference/rich-output-protocol

[earnest minnow]

https://docs.openclaw.ai/web/control-ui#chat-behavior

If you paste the version + the log lines around that run, we can tell whether this is the model failing to emit MEDIA:, or the Web UI/gateway failing to render a valid media attachment.

[unique atlas]

so looking in my browser log im getting a 401 error on the media

[earnest minnow]

Yep, that narrows it down: a 401 on /__openclaw__/assistant-media... means the image exists enough to be requested, but the media request is not authenticated.

The Control UI’s assistant-media route is protected by the same gateway auth as the rest of the UI. The UI should fetch it with a bearer/device token, or with a tokenized media URL. If that auth state is stale/missing, the chat text loads but the image request 401s.

Try this:

openclaw dashboard

Open the fresh dashboard URL it prints, or reconnect in the UI with the current Gateway Token from:

openclaw config get gateway.auth.token

Don’t paste that token here. After reconnecting, hard-refresh the Web UI and rerun the screenshot prompt.

[earnest minnow]

If you’re using a separate UI dev server or reverse proxy, make sure you opened it with the token fragment, e.g. #token=<gateway-token>, and that it points at the right gateway URL. Docs note this here: https://docs.openclaw.ai/web/control-ui#debuggingtesting-dev-server--remote-gateway

If it still 401s after a fresh openclaw dashboard URL, that smells like a UI auth forwarding bug or token drift. Please share openclaw --version plus whether the failing media URL is /__openclaw__/assistant-media or /api/chat/media/outgoing/....

[unique atlas]

so the image is being made, the agent cant find it,

It outputed { "content": [ { "type": "image", "mimeType": "image/png", "bytes": 50880, "omitted": true } ], "details": { "path": "/home/node/.openclaw/media/browser/ac044114-08a1-4f66-b6fa-ad5b249d30d5.png", "ok": true, "targetId": "BA310116A6CEACAAC3676F9654F7A4DD", "url": "https://www.google.com/", "media": { "mediaUrl": "/home/node/.openclaw/media/browser/ac044114-08a1-4f66-b6fa-ad5b249d30d5.png" } } }

Then couldnt figure how to send it, and went on a tagent trying to find a free api to generate screenshots

[earnest minnow]

That output is actually the smoking gun. The screenshot succeeded; the agent is just mishandling the tool result.

omitted: true means the image bytes weren’t dumped into the text/tool log, but the usable path is right there:

/home/node/.openclaw/media/browser/ac044114-08a1-4f66-b6fa-ad5b249d30d5.png

The agent should not search for a free screenshot API. It should put this in the final answer as media, exactly like:

MEDIA:/home/node/.openclaw/media/browser/ac044114-08a1-4f66-b6fa-ad5b249d30d5.png

or use the details.media.mediaUrl value from the browser tool result. It does not need to “find” or regenerate the file.

Try adding this to your agent instructions:

[earnest minnow]

When the browser screenshot tool returns details.media.mediaUrl or details.path, attach that exact path in the final reply using a standalone MEDIA:<path> line. Do not call external screenshot APIs.

If that produces the MEDIA: line but the image request still 401s in Web UI, that is the separate auth issue from before: refresh/reopen via openclaw dashboard so the UI has the current gateway token.

Please still drop openclaw --version when you can. If current builds are letting the model wander off instead of surfacing browser screenshot media automatically, that’s probably worth a GitHub issue: https://github.com/openclaw/openclaw/issues

[unique atlas]

So in the end it ended up fetching a random screenshot of google.com off the internet and then displayed that. So it can display media, just not from the browser.

OpenClaw 2026.5.12

[earnest minnow]

Yep, that’s a much clearer failure mode. Since remote/random media displays, the Web UI media renderer is basically fine. The broken part is specifically browser screenshot media getting from the browser tool result into a serveable Gateway/Web UI media URL.

On 2026.5.12, the browser tool is returning a filesystem path:

/home/node/.openclaw/media/browser/....png

That only works if the Gateway process can read that exact path. If the browser is running in a node host, Docker container, or different filesystem namespace, the agent sees a path that may not exist from the Gateway/Web UI side. Then the model gets confused and wanders off, which is bad behavior but downstream of the path issue.

Quick check from the machine/container running the Gateway:

test -r /home/node/.openclaw/media/browser/ac044114-08a1-4f66-b6fa-ad5b249d30d5.png && echo readable || echo not-readable

If Docker/compose is involved, run that inside the OpenClaw gateway container.