Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Feature]: Use assistant avatar in macOS Talk Mode overlay [1 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#70266•Fetched 2026-04-23 07:26:57
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
awaker72awaker72
Participants
awaker72awaker72
Timeline (top)
cross-referenced ×1

Allow macOS Talk Mode overlay to use the configured assistant avatar instead of always rendering the default orb.

Root Cause

Allow macOS Talk Mode overlay to use the configured assistant avatar instead of always rendering the default orb.

RAW_BUFFERClick to expand / collapse

Summary

Allow macOS Talk Mode overlay to use the configured assistant avatar instead of always rendering the default orb.

Problem to solve

OpenClaw already supports assistant identity in config, including ui.assistant.avatar, and users naturally expect that identity to carry through into voice interactions.

Today, when Talk Mode is opened in the macOS app, the overlay always renders the default animated orb in TalkOverlayView.swift. This breaks visual continuity between chat UI and voice UI. If a user has already configured a named assistant with a custom avatar, the Talk Mode overlay still looks generic instead of reflecting that assistant.

For character-driven assistants, personal companions, branded assistants, or multi-agent setups, this makes Talk Mode feel visually disconnected from the rest of the product.

Proposed solution

In the macOS app, update TalkOverlayView / TalkOrbView so Talk Mode can render the configured assistant avatar when available.

Suggested behavior:

  • If ui.assistant.avatar is configured and resolvable, show it as a circular cropped image in the Talk overlay.
  • Preserve the existing voice-state visuals by keeping the animated rings / pulse / thinking arcs around or above the avatar.
  • If no avatar is configured, fall back to the current orb behavior.
  • Optionally make this toggleable later, but the fallback behavior already keeps this backward-compatible.

Alternatives considered

  • Keep the generic orb only

    • Simple, but loses assistant identity and visual continuity.

  • Replace the orb entirely with a static avatar and remove all motion

    • Would preserve identity, but loses useful speaking/listening/thinking state cues.

  • Support this only in web UI

    • Doesn't help the macOS Talk Mode overlay, which is where the visual mismatch is most obvious.

Impact

Affected users/systems/channels: macOS app users who use Talk Mode, especially users with custom assistant personas, custom branding, or multiple agents.

Severity: Minor to moderate UX issue. It does not block use, but it makes Talk Mode feel generic and inconsistent with the configured assistant identity.

Frequency: Every time Talk Mode is opened on macOS.

Consequence: Users see a mismatch between the assistant they configured and the assistant shown in voice mode. This is especially noticeable for personal assistant setups and brand/character-driven agent experiences.

Evidence/examples

Current implementation appears to always render the orb directly in apps/macos/Sources/OpenClaw/TalkOverlayView.swift, via TalkOrbView using Circle()-based rendering.

That makes this feel like a good targeted enhancement with a clear fallback path.

Additional information

Related issue:

  • #22199 Per-agent UI identity overrides (name, emoji, avatar)

This request is narrower and specifically about carrying assistant avatar identity into the macOS Talk Mode overlay.

extent analysis

TL;DR

Update TalkOverlayView and TalkOrbView in the macOS app to render the configured assistant avatar when available, preserving existing voice-state visuals.

Guidance

  • Review the TalkOverlayView.swift file to understand the current implementation of the Talk Mode overlay.
  • Update TalkOrbView to conditionally render the ui.assistant.avatar as a circular cropped image when it is configured and resolvable.
  • Ensure the existing voice-state visuals, such as animated rings, pulse, and thinking arcs, are preserved around or above the avatar.
  • Implement a fallback to the current orb behavior when no avatar is configured.

Example

// Pseudocode example, actual implementation may vary
if let avatar = ui.assistant.avatar, avatar.isResolvable {
    // Render avatar as circular cropped image
    TalkOrbView(avatar: avatar)
} else {
    // Fall back to current orb behavior
    TalkOrbView()
}

Notes

The proposed solution aims to enhance the user experience by maintaining visual continuity between the chat UI and voice UI. However, the actual implementation details may vary depending on the specific requirements and constraints of the project.

Recommendation

Apply the proposed workaround by updating TalkOverlayView and TalkOrbView to render the configured assistant avatar, as it provides a more personalized and consistent user experience.

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…
#runtime error#dependency conflict#environment setup#docker error#agent 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 - 💡(How to fix) Fix [Feature]: Use assistant avatar in macOS Talk Mode overlay [1 participants]