Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Control UI: assistant-media preview returns 401 in device-token sessions even when chat works [1 pull requests, 2 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#70505•Fetched 2026-04-24 05:57:16
View on GitHub
Comments
2
Participants
2
Timeline
8
Reactions
0
Author
pavelknezikpavelknezik
Participants
Patrick-ErichsenPatrick-Erichsenpavelknezikpavelknezik
Timeline (top)
commented ×2labeled ×2closed ×1cross-referenced ×1

In Control UI, assistant-generated media attachments (for example MEDIA:/...png) fail to render with 401 Unauthorized, even though the chat session itself is working.

This appears to be an auth mismatch between:

  • websocket/device-token session auth used by the chat UI
  • HTTP auth required by GET /__openclaw__/assistant-media

Important observation

This is not a filesystem permissions problem.

Why:

  • Generated files exist on disk
  • 401 means the request failed auth before the backend even got to file/root validation
  • If it were a path/root/existence problem, expected result would be closer to:
    • 200 { "available": false, ... }
    • or `404

Root Cause

Suspected root cause

Fix Action

Fixed

PR fix notes

PR #70741: fix(control ui): accept paired device token for assistant media auth

Description (problem / solution / changelog)

Fixes #70505 (partially)

  • accept paired device-token auth on assistant-media, including the existing ?token= Control UI path
  • keep the current media URL behavior for now

Follow-up:

  • #70830

Tests:

  • pnpm test src/gateway/control-ui.http.test.ts
  • pnpm test ui/src/ui/chat/grouped-render.test.ts

Changed files

  • src/gateway/control-ui.http.test.ts (modified, +124/-1)
  • src/gateway/control-ui.ts (modified, +68/-8)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In Control UI, assistant-generated media attachments (for example MEDIA:/...png) fail to render with 401 Unauthorized, even though the chat session itself is working.

This appears to be an auth mismatch between:

  • websocket/device-token session auth used by the chat UI
  • HTTP auth required by GET /__openclaw__/assistant-media

Important observation

This is not a filesystem permissions problem.

Why:

  • Generated files exist on disk
  • 401 means the request failed auth before the backend even got to file/root validation
  • If it were a path/root/existence problem, expected result would be closer to:
    • 200 { "available": false, ... }
    • or `404

Steps to reproduce

  1. Open Control UI in a session authenticated through paired-device / device-token flow
  2. Generate or receive an assistant reply containing a local media attachment, e.g. MEDIA:/home/.../.openclaw/media/...png
  3. Control UI tries to render the attachment through:
    • /__openclaw__/assistant-media?source=...
  4. Request returns 401 Unauthorized
  5. Attachment preview fails

Expected behavior

If Control UI chat is authenticated and allowed to view the message, assistant media previews should render without requiring a manually exposed gateway token in the URL.

Actual behavior

Chat works, but assistant-media HTTP preview returns 401 Unauthorized.

Additional information

When Control UI is opened using a shared gateway token, the same media can become visible.

That strongly suggests the issue is not media generation or local file access, but auth selection / auth propagation for the assistant-media HTTP endpoint.

Suspected root cause

assistant-media is served through an HTTP route that authorizes via shared gateway HTTP auth, while the UI may prefer websocket/device token auth for the active session.

Relevant UI auth behavior currently prefers:

  • hello.auth.deviceToken
  • then settings.token
  • then password

This can make chat work over websocket while media preview still fails over HTTP.

Related files

UI:

  • ui/src/ui/control-ui-auth.ts

Gateway/backend:

  • src/gateway/control-ui.ts
    • handleControlUiAssistantMediaRequest(...)
    • authorizeControlUiReadRequest(...)
  • src/gateway/server-http.ts

Security note

Using ?token=... in assistant-media URLs is not an acceptable final fix because it exposes long-lived gateway auth material in browser-visible URLs / DOM / network logs.

A safer fix would likely be one of:

  • header-based authenticated fetch + blob URLs
  • short-lived signed media tickets scoped to assistant-media access

OpenClaw version

v2026.4.22

Operating system

Debian

Install method

No response

Model

openai-codex/gpt5.4

Provider / routing chain

openclaw

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

extent analysis

TL;DR

The most likely fix is to implement header-based authenticated fetch or short-lived signed media tickets for the assistant-media HTTP endpoint to resolve the auth mismatch.

Guidance

  • Investigate the authorizeControlUiReadRequest function in src/gateway/control-ui.ts to understand how it handles authentication for the assistant-media endpoint.
  • Consider modifying the handleControlUiAssistantMediaRequest function to accept websocket/device token auth or implement a token exchange mechanism.
  • Review the ui/src/ui/control-ui-auth.ts file to ensure it is using the correct authentication method for the assistant-media endpoint.
  • Test the fix by verifying that the assistant-media preview renders correctly without requiring a manually exposed gateway token in the URL.

Example

No code example is provided as the issue requires a deeper understanding of the authentication mechanisms used in the application.

Notes

The fix should prioritize security and avoid exposing long-lived gateway auth material in browser-visible URLs or DOM. The use of header-based authenticated fetch or short-lived signed media tickets is recommended.

Recommendation

Apply a workaround by implementing header-based authenticated fetch or short-lived signed media tickets for the assistant-media HTTP endpoint, as this approach addresses the auth mismatch while maintaining security.

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

If Control UI chat is authenticated and allowed to view the message, assistant media previews should render without requiring a manually exposed gateway token in the URL.

#request error#file not found#serialization error#model compatibility#GPU setup

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]: Control UI: assistant-media preview returns 401 in device-token sessions even when chat works [1 pull requests, 2 comments, 2 participants]