Fix tray app display name branding

[bkudiess]

Summary

• Use OpenClaw Companion / OpenClaw Companion (Dev) as the visible app identity for toast sender fallback, unpackaged app metadata, and approval/permission popup titles.
• Align runtime AppUserModelID with installer shortcut AUMIDs so Windows does not fall back to OpenClaw.Tray.WinUI for notifications.
• Remove localized recording-consent OpenClaw · prefixes to avoid double-branded titles.
• Add contract coverage for startup AUMID registration, installer shortcut AUMIDs, popup branding, manifest identity, and metadata.

Validation

• ./build.ps1 — passed
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — passed (2703 passed, 31 skipped)
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — passed (1592 passed)

Real behavior proof

• Built current-head WinUI executable reports:
  • FileDescription: OpenClaw Companion
  • ProductName: OpenClaw Companion
• Live current-head popup proof captured from an isolated tray run of this branch:
  • Process path: C:\Projects\copilot-worktrees\openclaw-windows-node\bkudiess-symmetrical-carnival\src\OpenClaw.Tray.WinUI\bin\Debug\net10.0-windows10.0.22621.0\win-arm64\OpenClaw.Tray.WinUI.exe
  • Trigger: winnode --mcp-port 18766 --command system.run --params '{"command":"cmd","args":["/c","echo proof-current-head-unique-946"],"timeoutMs":30000}'
  • Copied UI diagnostic transcript from the active native approval popup:

Window: "OpenClaw Companion - Approve local command?", App: OpenClaw.Tray.WinUI.
  AXWindow OpenClaw Companion - Approve local command?
    AXStaticText OpenClaw Companion - Approve local command?
    AXScrollArea Value: OpenClaw Companion needs approval before a remote agent can run a local command on this Windows machine.
      cmd /c "echo proof-current-head-unique-946"
      Shell: cmd
      Reason: No matching rule; default policy applied
    AXButton Allow once
    AXButton Always allow
    AXButton Deny
    AXTitleBar Value: OpenClaw Companion - Approve local command?

• Current-head source/contract tests verify:
  • Runtime AppUserModelID uses OpenClaw.Companion / OpenClaw.Companion.Dev.
  • Installer Start Menu, setup, settings, chat, update, desktop, and startup shortcuts carry {#MyAppAumid}.
  • Pairing, recording consent, and local command approval popups use AppIdentity.DisplayName.
  • Recording consent localized titles no longer include OpenClaw ·, preventing double-branding.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 8, 2026, 7:24 PM ET / 23:24 UTC.

Summary
The PR aligns tray branding across runtime AppUserModelID registration, installer shortcut AUMIDs, app metadata, manifest identity, native approval/permission popup titles, localized recording-consent strings, and tray contract tests.

Reproducibility: yes. at source level: current main lacks installer AppUserModelID wiring and still uses OpenClaw.Tray.WinUI in the unpackaged manifest. I did not run a live Windows repro in this read-only review, but the PR body includes current-head native popup proof.

Review metrics: 2 noteworthy metrics.

• Changed surface: 17 files, +197/-26. The patch is focused but spans installer metadata, WinUI identity, native prompts, localized strings, and tests.
• Shortcut AUMID coverage: 7 shortcut entries updated. Start Menu, desktop, and startup launch surfaces are affected, so maintainers should notice the shell identity scope before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Have a maintainer explicitly accept the AUMID/manifest/shortcut upgrade risk, or request installed-upgrade toast/shortcut proof before merge.

Risk before merge

• [P1] Changing runtime AppUserModelID, manifest identity, and installer shortcut AUMIDs can affect notification grouping, shortcut behavior, or shell identity for existing Windows installs after upgrade.
• [P1] The proof covers executable metadata and a live native approval popup, while installed-upgrade toast sender and shortcut AUMID behavior remain source/contract-tested rather than shown in an upgraded install.

Maintainer options:

1. Accept current shell identity proof (recommended)
   Maintainers can merge with the current source contracts and live popup proof while explicitly accepting the upgrade behavior risk for notifications and shortcuts.
2. Ask for installed-upgrade shell proof
   Request a short redacted installed or upgraded Windows run showing the corrected toast sender or shortcut AUMID behavior before merge.
3. Split out shell identity changes
   Pause or replace this PR if maintainers only want visible prompt/metadata branding and not AppUserModelID or manifest identity changes yet.

Next step before merge

• [P2] A maintainer needs to accept or request more proof for Windows shell identity upgrade behavior; no narrow automated repair is indicated.

Maintainer decision needed

• Question: Is the OpenClaw.Companion AppUserModelID, manifest identity, and installer shortcut identity change acceptable for existing Windows installs with the current proof package?
• Rationale: The code path looks technically sound, but Windows shell identity changes can affect upgrade behavior, notification grouping, and shortcuts in ways source tests and popup proof cannot fully settle.
• Likely owner: karkarl — karkarl introduced the AppIdentity and side-by-side identity structure that this PR extends with shell AUMID behavior.
• Options:
  • Accept the shell identity alignment (recommended): Merge with the current validation and live popup proof, with maintainers owning the remaining Windows shell upgrade behavior risk.
  • Require installed-upgrade proof first: Ask for a redacted installed or upgraded run showing corrected toast sender or shortcut AUMID behavior before merge.
  • Defer the AUMID/manifest portion: Keep only prompt and metadata branding now, and postpone shell identity changes until maintainers define a narrower upgrade-proof requirement.

Security
Cleared: The diff adds Windows identity P/Invokes and installer metadata changes, but no new dependency, workflow, secret, permission broadening, or executable-download path was found.

Review details

Best possible solution:

Land the focused branding/AUMID alignment after maintainers accept the Windows shell identity upgrade behavior, keeping AppIdentity as the source of truth and retaining the contract tests.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: current main lacks installer AppUserModelID wiring and still uses OpenClaw.Tray.WinUI in the unpackaged manifest. I did not run a live Windows repro in this read-only review, but the PR body includes current-head native popup proof.

Is this the best way to solve the issue?

Yes: centralizing the AUMID through AppIdentity and aligning process registration, installer shortcuts, metadata, manifest identity, and prompt titles is the narrow maintainable fix. The remaining concern is maintainer acceptance of shell identity upgrade behavior, not a concrete code defect.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 02f2421a5e75.

Label changes

Label justifications:

• P3: This is a focused tray branding and notification identity polish fix with limited blast radius and no urgent user-blocking evidence.
• merge-risk: 🚨 compatibility: Changing AppUserModelIDs, shortcut metadata, and manifest identity can affect existing Windows shell notification and launch behavior during upgrades.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes current-head validation plus copied live UI diagnostic output from an isolated tray run showing the changed native approval popup branding.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes current-head validation plus copied live UI diagnostic output from an isolated tray run showing the changed native approval popup branding.

Evidence reviewed

What I checked:

• AGENTS.md policy read and applied: Repository policy was read fully; its tray UX proof and validation guidance applies to this review, while the ClawSweeper review contract keeps the checkout read-only. (AGENTS.md:57, 02f2421a5e75)
• Current main has the installer AUMID gap: Current main installer shortcut entries do not set AppUserModelID, matching the notification/shell fallback branding problem the PR targets. (installer.iss:115, 02f2421a5e75)
• Current main still exposes internal manifest identity: Current main unpackaged manifest uses OpenClaw.Tray.WinUI as the assembly identity, which is the internal name the PR is trying to remove from visible Windows surfaces. (src/OpenClaw.Tray.WinUI/app.manifest:3, 02f2421a5e75)
• PR merge result aligns installer shortcuts: The synthetic merge result defines release/dev MyAppAumid values and applies them to Start Menu, desktop, and startup shortcut entries. (installer.iss:117, f2a430516b56)
• PR merge result registers runtime AUMID early: The synthetic merge result registers AppIdentity.AppUserModelId before settings and app services initialize, and logs failed registration HRESULTs. (src/OpenClaw.Tray.WinUI/App.xaml.cs:478, f2a430516b56)
• PR merge result preserves current branding control: The merge result applies the new companion title while preserving the current main BrandMark control in the pairing and recording dialogs, so stale raw-head branding does not survive the three-way merge. (src/OpenClaw.Tray.WinUI/Dialogs/PairingApprovalDialog.cs:58, f2a430516b56)

Likely related people:

• karkarl: PR feat: add dev/release side-by-side app identity #922 introduced the AppIdentity and side-by-side installer identity structure that this PR extends with AUMIDs. (role: introduced identity structure; confidence: high; commits: dae64b6c49e9; files: src/OpenClaw.Tray.WinUI/AppIdentity.cs, installer.iss, src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj)
• steipete: GitHub metadata shows steipete merged the side-by-side identity PR that established the current identity boundary under review here. (role: identity PR merger; confidence: medium; commits: dae64b6c49e9; files: src/OpenClaw.Tray.WinUI/AppIdentity.cs, installer.iss)
• shanselman: Blame shows the current installer shortcut entries and native approval prompt baseline trace to commit 4166e0f. (role: introduced current installer and prompt baseline; confidence: medium; commits: 4166e0fd63f8; files: installer.iss, src/OpenClaw.Tray.WinUI/Services/ExecApprovalPromptService.cs, src/OpenClaw.Tray.WinUI/Dialogs/PairingApprovalDialog.cs)
• bkudiess: Recent merged branding work touched the same dialog surfaces, so bkudiess is relevant beyond authorship of this PR. (role: recent branding and tray UX contributor; confidence: high; commits: 0d11a8ae6a49; files: src/OpenClaw.Tray.WinUI/Dialogs/PairingApprovalDialog.cs, src/OpenClaw.Tray.WinUI/Dialogs/RecordingConsentDialog.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (2 earlier review cycles)

• reviewed 2026-07-08T22:29:47.149Z sha 312fd59 :: needs maintainer review before merge. :: none
• reviewed 2026-07-08T23:18:53.002Z sha 312fd59 :: needs maintainer review before merge. :: none

[bkudiess]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.