openclaw - ✅(Solved) Fix [Bug]: Control UI ignores assistantAvatar and renders favicon.svg [3 pull requests, 3 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#71422Fetched 2026-04-26 05:12:55
View on GitHub
Comments
3
Participants
2
Timeline
12
Reactions
0
Participants
Timeline (top)
commented ×3cross-referenced ×3referenced ×3closed ×1

After upgrading to OpenClaw 2026.4.23, the assistant avatar no longer renders in chat.

Before the upgrade, I used IDENTITY.md to configure:

Avatar: avatars/aemis.jpeg

After the upgrade, the chat avatar falls back to the default OpenClaw favicon/lobster avatar.

To rule out IDENTITY.md parsing or config-source conflicts, I removed the Avatar entry from IDENTITY.md and configured the same path only through:

Web UI -> Appearance & Settings -> UI -> Assistant Appearance -> Assistant Avatar

Value: avatars/aemis.jpeg

The issue still reproduces.

Root Cause

After upgrading to OpenClaw 2026.4.23, the assistant avatar no longer renders in chat.

Before the upgrade, I used IDENTITY.md to configure:

Avatar: avatars/aemis.jpeg

After the upgrade, the chat avatar falls back to the default OpenClaw favicon/lobster avatar.

To rule out IDENTITY.md parsing or config-source conflicts, I removed the Avatar entry from IDENTITY.md and configured the same path only through:

Web UI -> Appearance & Settings -> UI -> Assistant Appearance -> Assistant Avatar

Value: avatars/aemis.jpeg

The issue still reproduces.

Fix Action

Fixed

PR fix notes

PR #71464: fix(control-ui): always blobify relative avatar URLs in refreshChatAvatar

Description (problem / solution / changelog)

Fixes openclaw/openclaw#71422

Problem

After upgrading to OpenClaw 2026.4.23, the configured assistant avatar renders as the default favicon.svg instead of the custom image in the Control UI chat view.

Root cause

Commit 2ce16e558e (which added auth requirements for avatar routes) introduced a condition in refreshChatAvatar:

if (!authHeader || !isLocalControlUiAvatarUrl(avatarUrl)) {
  setChatAvatarUrl(host, avatarUrl);
  return;
}

The !authHeader || guard caused relative avatar URLs (e.g. /avatar/main) to be set directly as chatAvatarUrl when no auth token was present, bypassing blob conversion. Relative URLs must always be fetched with auth and converted to blob URLs because the browser cannot attach the Authorization header to a direct <img src> request.

Fix

Remove the !authHeader || guard so only non-relative (external) URLs bypass blob conversion:

if (!isLocalControlUiAvatarUrl(avatarUrl)) {
  setChatAvatarUrl(host, avatarUrl);
  return;
}
// Always fetch + blobify relative URLs

The fetch call already handles null authHeader gracefully (passes undefined as headers).

Test update

The test that expected the broken behavior (chatAvatarUrl = '/avatar/main' raw) is updated to properly mock the avatar fetch and expect a blob URL.


Before — configured avatar renders as favicon.svg After — configured avatar renders correctly as blob URL

Changed files

  • ui/src/ui/app-chat.test.ts (modified, +92/-5)
  • ui/src/ui/app-chat.ts (modified, +2/-2)

PR #71512: fix(control-ui): fetch protected avatar route with device token and use blob URL

Description (problem / solution / changelog)

Fixes #71422.

Root cause: Commit 2ce16e558e (fix #69775) added auth to the /avatar/* route. The refreshChatAvatar function fetches avatar/{agentId}?meta=1 (unauthenticated, still public) which returns {"avatarUrl": "/avatar/main"}, then stored that relative path in chatAvatarUrl. The chat renderer set that path directly as <img src="/avatar/main"> — which the browser cannot fetch without an Authorization header, so the image silently fails.

Fix: After resolving the avatarUrl from the meta endpoint, if the path is relative (not http/data URL) and a device token is available, fetch the image with Authorization: Bearer <deviceToken> and store a blob: URL instead. The browser can render blob URLs without HTTP auth headers.

Behavior preserved:

  • External http/data avatar URLs: used directly (unchanged)
  • No device token (pre-auth state): path stored as-is (existing test passes)
  • Device token present: image fetched with auth, blob URL stored (new test)

Tests: 3 pass (app-chat.test.ts), including a new case verifying the authenticated fetch and blob URL path.

Changed files

  • .gitignore (modified, +1/-0)
  • tasks/contributor-status.md (added, +61/-0)
  • tasks/evening-report.md (added, +90/-0)
  • tasks/midday-check.md (added, +38/-0)
  • tasks/pr-monitor-report.md (added, +138/-0)
  • ui/src/ui/app-chat.test.ts (modified, +29/-0)
  • ui/src/ui/app-chat.ts (modified, +26/-1)

PR #71518: fix: render authenticated control ui avatars

Description (problem / solution / changelog)

Replacement maintainer rewrite for #71464 and #71512.

Fixes #71422.

Summary:

  • fetch route-relative Control UI avatar images into managed blob URLs even when no auth header is available
  • keep existing blob URL revocation/stale-response guards
  • allow locally generated avatar blobs in the Control UI CSP without allowing remote http(s) images
  • update Control UI CSP docs and regression coverage

Validation:

  • pnpm test ui/src/ui/app-chat.test.ts ui/src/ui/chat/grouped-render.test.ts ui/src/ui/views/agents-utils.test.ts src/gateway/control-ui-csp.test.ts
  • pnpm tsgo:prod
  • pnpm check:docs
  • pnpm check:changed

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • docs/web/control-ui.md (modified, +3/-2)
  • src/gateway/control-ui-csp.test.ts (modified, +3/-3)
  • src/gateway/control-ui-csp.ts (modified, +1/-1)
  • ui/src/ui/app-chat.test.ts (modified, +57/-5)
  • ui/src/ui/app-chat.ts (modified, +2/-2)

Code Example

{
  "assistantName": "AEMIS",
  "assistantAvatar": "/avatar/main",
  "assistantAgentId": "main",
  "serverVersion": "2026.4.23"
}

---

{"avatarUrl":"/avatar/main"}

---

Status: 200
Content-Type: image/jpeg
Content-Length: 77611

---

<img class="chat-avatar assistant chat-avatar--logo" src="favicon.svg" alt="AEMIS">

---

https://github.com/github.png?size=128

---
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to OpenClaw 2026.4.23, the assistant avatar no longer renders in chat.

Before the upgrade, I used IDENTITY.md to configure:

Avatar: avatars/aemis.jpeg

After the upgrade, the chat avatar falls back to the default OpenClaw favicon/lobster avatar.

To rule out IDENTITY.md parsing or config-source conflicts, I removed the Avatar entry from IDENTITY.md and configured the same path only through:

Web UI -> Appearance & Settings -> UI -> Assistant Appearance -> Assistant Avatar

Value: avatars/aemis.jpeg

The issue still reproduces.

Steps to reproduce

  1. Start OpenClaw 2026.4.23.
  2. Open the Control UI at http://127.0.0.1:18789/.
  3. Go to Appearance & Settings -> UI -> Assistant Appearance.
  4. Set Assistant Name to AEMIS.
  5. Set Assistant Avatar to a workspace-relative image path: avatars/aemis.jpeg.
  6. Click Save/Update and refresh the Control UI.
  7. Confirm GET /__openclaw/control-ui-config.json returns "assistantAvatar": "/avatar/main".
  8. Confirm GET /avatar/main?meta=1 returns {"avatarUrl":"/avatar/main"}.
  9. Confirm GET /avatar/main with Authorization: Bearer <gateway token> returns 200 with Content-Type: image/jpeg and the expected image.
  10. Inspect the rendered assistant chat avatar in the DOM.

Expected behavior

The assistant chat avatar should render the configured avatar image.

For the workspace-relative avatar path avatars/aemis.jpeg, the Control UI should use the resolved avatar route /avatar/main, fetch it with the gateway token, create an authenticated blob URL, and render that image in the chat avatar.

This matches the Control UI docs under "Avatar route auth", which say the Control UI forwards the gateway token when fetching avatars and uses authenticated blob URLs so the image still renders in dashboards.

Actual behavior

The assistant name is applied, but the configured assistant avatar is not rendered.

GET /__openclaw/control-ui-config.json returns 200 and includes:

{
  "assistantName": "AEMIS",
  "assistantAvatar": "/avatar/main",
  "assistantAgentId": "main",
  "serverVersion": "2026.4.23"
}

GET /avatar/main?meta=1 returns 200:

{"avatarUrl":"/avatar/main"}

GET /avatar/main with Authorization: Bearer <gateway token> returns the expected custom avatar image:

Status: 200
Content-Type: image/jpeg
Content-Length: 77611

The response preview shows the expected image.

However, the rendered assistant chat avatar is still:

<img class="chat-avatar assistant chat-avatar--logo" src="favicon.svg" alt="AEMIS">

So the avatar route works, but the chat renderer falls back to favicon.svg.

I also tested an external HTTPS avatar URL:

https://github.com/github.png?size=128

/__openclaw/control-ui-config.json then returns that URL as assistantAvatar, and /avatar/main?meta=1 returns the same URL, but the chat avatar renders as a fallback SVG star icon instead of the image.

OpenClaw version

2026.4.23

Operating system

macOS 26.4.1 arm64

Install method

No response

Model

mimo-v2.5-pro/qwen3.6-plus/text-embedding-v4

Provider / routing chain

npm global under nvm

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue might be related to how the Control UI handles authenticated blob URLs for workspace-relative avatar paths in OpenClaw 2026.4.23, requiring a potential fix in how avatar URLs are resolved or authenticated.

Guidance

  • Verify that the avatars/aemis.jpeg image exists in the expected location and is accessible by the OpenClaw server.
  • Check the browser's network requests to see if the avatar image is being fetched correctly with the gateway token and if there are any errors in the request or response.
  • Test using an external HTTPS avatar URL to see if the issue is specific to workspace-relative paths or if it's a more general avatar rendering problem.
  • Inspect the DOM and JavaScript code responsible for rendering the chat avatar to understand why it falls back to the default favicon despite the correct configuration.

Example

No specific code example can be provided without more details on the OpenClaw configuration or the exact code responsible for rendering the chat avatar. However, ensuring that the avatar URL is correctly resolved and authenticated might involve checking the GET /avatar/main request headers and response.

Notes

The issue seems specific to OpenClaw version 2026.4.23 and might be related to changes in how avatar URLs are handled or authenticated. Without more information on the internal workings of OpenClaw or access to its source code, providing a precise fix is challenging.

Recommendation

Apply a workaround by using an external HTTPS avatar URL if possible, as this might bypass the issue with workspace-relative paths, although this does not address the root cause and might not be desirable for all use cases.

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

The assistant chat avatar should render the configured avatar image.

For the workspace-relative avatar path avatars/aemis.jpeg, the Control UI should use the resolved avatar route /avatar/main, fetch it with the gateway token, create an authenticated blob URL, and render that image in the chat avatar.

This matches the Control UI docs under "Avatar route auth", which say the Control UI forwards the gateway token when fetching avatars and uses authenticated blob URLs so the image still renders in dashboards.

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 ignores assistantAvatar and renders favicon.svg [3 pull requests, 3 comments, 2 participants]