Repository navigation
feat: show Gateway agent names and avatars across the Windows app - #2044
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
@clawsweeper[bot] /review |
|
|
|
Codex review: needs maintainer review before merge. What this changesThis PR displays Gateway-resolved agent names and avatars across Workspace selectors, chat welcome views, and assistant transcript rows. Example: The Gateway's default agent has routing ID main and resolves to Assistant.
Review scores
ProductKind: Feature · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open: it provides useful identity presentation still missing from main, and review found no actionable introduced defect. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherGateway roster and identity responses enter the existing authenticated client, are composed into connection-scoped presentation state, and feed native Workspace and Reactor chat controls. flowchart TD
Gateway[Gateway roster and identities] --> Client[Authenticated Gateway client]
Client --> Service[GatewayService]
Service --> State[AppState]
State --> Presentation[Agent presentation]
Presentation --> Workspace[Workspace selector]
Presentation --> Chat[Welcome and transcript]
Chat --> Images[Bounded image cache]
Technical reviewBest possible solution: Keep one roster-first presentation policy in the existing Gateway, AppState, and badge owners, with resolved identity fallback and bounded chat image loading. Do we have a high-confidence way to reproduce the issue? Current-main source shows the raw-ID fallback and separate transcript avatar path; no target code, build, or test was executed during this read-only review. Is this the best way to solve the issue? The change fixes presentation at existing owners, preserves routing IDs and selection behavior, and uses a justified shared cache rather than loading an image separately for every transcript row. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 1d8e42687247. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
Preflight sourceSource unknown. Source comparison at the observed PR snapshot only. Completion is self-reported; body, policy, tests, execution, and report bytes are not verified. Review metrics
LabelsLabel changes:
Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReviewed November 6, 2026, 7:54 PM ET / November 7, 2026, 00:54 UTC (Revision 3). |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
The Windows app asks the Gateway for each roster agent's identity (agent.identity.get) so it can show the agent's name and avatar. The mock Gateway did not implement it, so every request returned METHOD_NOT_FOUND and was recorded as an unexpected request. That fails the strict empty UnexpectedRequests assertions in the mock Gateway application scenarios and in the latest stable profile compatibility step. Serve the method from the scenario roster, plus the agent created by the agent-creation scenario. The result carries the roster name and no avatar, so the app renders its generated face. An unknown agent id gets INVALID_REQUEST, as on a real Gateway, which is an ordinary protocol error rather than an unexpected request. Advertise the method with the other read methods and document it. Covered by protocol tests that drive the real client against the fixture: each roster agent, a created agent, an unknown agent, and parameter validation. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Resolve one conflict, in tests/OpenClaw.Shared.Tests/GatewayFixtureProtocolTests.cs. main removed the native Channels page (openclaw#1930) and deleted the three channels.status rows from RealClient_InvalidOrUnknownParametersFailExplicitly. This branch added two agent.identity.get rows at the same spot. Keep the two agent.identity.get rows and drop the three channels.status rows. main's deletion is preserved, and the fixture still rejects malformed agent.identity.get requests. No other file needed manual resolution. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
Preserve the avatar identity regression while retaining main's removal of retired agent-event state and tests. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>


What Problem This Solves
Fixes: Gateway agent names and avatars are missing or shown as the raw
mainID in Windows workspace and chat views.User Impact
User impact: Workspace selectors, chat welcome surfaces, and assistant transcript rows show Gateway-resolved agent names and avatars. The default agent retains its
mainrouting ID and displays asAssistant.Why This Change Was Made
Use roster-first presentation with Gateway identity fallback scoped to the active client, share bounded avatar image loading, and keep the whole avatar inside its slot. Refreshed roster identity takes precedence over retained chat-placement metadata.
Evidence
Change Type
Scope
winnodeRequired proof pools
windows-winui-interactive: Workspace and chat identity/avatar rendering changed. The live captures below are partial evidence, not completion of the full pool.Validation
All current-head results below use
68299c8d8193297e07b46e016ed1dabda36cf022.pwsh -NoProfile -ExecutionPolicy Bypass -File .\build.ps1: passed, Debugwin-x64, including documentation checks.dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --filter "FullyQualifiedName~GatewayFixtureProtocolTests": 134 passed, 0 skipped.dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj: 4,873 passed, 25 opt-in skips, 0 failed.dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj: 5,279 passed, 0 skipped.With isolated tray data roots and
$runset to the session's result directory:Result: 5 passed, 0 skipped, 0 failed. Both selector theory cases ran.
PR checks at this head: 19 passed, 7 release-only checks skipped, 0 failed. In CI run 42313873727, the fixture application lane passed 38/38, fixture UI lane 78/78, and stable-profile compatibility 1/1.
Earlier on
f1ec5d2d,.\scripts\run-proof-tests.ps1 -Project 'tests\OpenClaw.Tray.UITests\OpenClaw.Tray.UITests.csproj' -Filter 'Category=Accessibility' -ResultName 'winui-accessibility' -RuntimeIdentifier win-x64had 22 passes and 11 skips; the runner rejected the skipped opt-in tests, so this is not complete proof-pool validation.An earlier UI invocation using AnyCPU failed before tests because Windows App SDK requires an explicit architecture. The x64 invocations passed.
Real Behavior Proof
ws://127.0.0.1:18789.68299c8d8193297e07b46e016ed1dabda36cf022; the Debug executable's product version contains that commit and its SHA256 is60399B219081E98A03B082F55F29FAB1C84FC17C82E112C84ECDCA1AAF4B1906.Assistantwith stable IDmain; the welcome and assistant transcript both show the complete generated face. Owner identity and existing conversation content are masked.hello-okhandshakes and fouragent.identity.getsends, with no logged identity-hydration failure. The run logged nochat.sendor Gatewayconfig.set,config.patch, orconfig.applyrequest.Yes/No/N/A): Yes, after publishing the two redacted images below.sessions.patchwas also observed before creation, but its target and payload were not logged.Connected welcome and selector
Assistant transcript
Security Impact
Yes/No): No.Yes/No): No.Yes/No): Yes, read-only Gateway identity and avatar retrieval for listed agents; requests use the existing authenticated Gateway client and bounded media resolver.Yes/No): No.Yes/No): Yes, read-only agent identity metadata for the Gateway roster; no user content or credentials are added.Yes, explain the risk and mitigation: Reads stay on the selected Gateway connection, identity results are invalidated on client replacement, and avatar loading follows existing media host and decoding protections.Compatibility and Migration
Yes/No): Yes.Yes/No): No.Yes/No): No.N/A.
Review Conversations