Notifications tab never shows notifications despite Windows Notification Center having them

[QQSHI13]

Problem

The Settings → Notifications tab (backed by AppNotificationService) is perpetually empty, even though plenty of OpenClaw notifications appear in the Windows Notification Center (backed by ToastService) and in the Windows action center.

Root Cause

AppNotificationService.Show() (in-app notification) and ToastService.ShowToast() (Windows Notification Center) are completely siloed:

Notification type	In-app Notifications tab	Windows Notification Center
Exec-approval denials	✅ (_appNotificationService.Show())	❌
Everything else (gateway events, node activity, chat, system, pairing, etc.)	❌	✅ (_toastService.ShowToast())

There is exactly one call to _appNotificationService.Show() in the entire codebase (App.xaml.cs:2244), and it only fires for exec-approval denials.

Affected code

• src/OpenClaw.Tray.WinUI/Services/AppNotificationService.cs — the in-app notification service (works, but nobody calls it)
• src/OpenClaw.Tray.WinUI/App.xaml.cs — ~30+ calls to _toastService.ShowToast(), none of which also call _appNotificationService.Show()

Expected behavior

Every notification that reaches the tray should appear in both:

1. The in-app Notifications tab (via AppNotificationService)
2. The Windows Notification Center / toast popup (via ToastService)

Suggested fix

Create a single notification dispatch method that calls both services, then route every callsite through it:

private void ShowNotification(AppNotification appNotification, ToastContentBuilder? toastBuilder = null)
{
    _appNotificationService?.Show(appNotification);
    if (toastBuilder is not null)
        _toastService?.ShowToast(toastBuilder);
}

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 2:38 AM ET / 06:38 UTC.

Summary
Keep open: current main still routes most tray-visible notifications through Windows toasts only, while the in-app Notifications page renders only AppNotificationService items.

Reproducibility: yes. from source: trigger a gateway, node, pairing, or system.notify toast and the code calls ToastService without adding an AppNotification, so the Notifications tab has nothing to render. I did not run the Windows UI smoke.

Next step
A focused repair is plausible, but it should preserve existing toast behavior and avoid turning every transient toast into a persistent in-app item.

Review details

Best possible solution:

Add a shared tray notification dispatch path that records eligible AppNotification entries alongside toasts while preserving notification settings, toast dedupe, and chat toast session arguments.

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

Yes, from source: trigger a gateway, node, pairing, or system.notify toast and the code calls ToastService without adding an AppNotification, so the Notifications tab has nothing to render. I did not run the Windows UI smoke.

Is this the best way to solve the issue?

Yes, the suggested shared dispatch helper is the right general direction, but the implementation should classify persistence and dedupe rather than blindly persisting every transient toast.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• I did not run a Windows tray smoke in this read-only review; the failure is source-reproducible from current main.
• A blanket mirror of every toast could make transient confirmations persistent in the Notifications tab, so the fix should define source, dedupe, and persistence for each notification class.

Codex review notes: model internal, reasoning high; reviewed against 4e7982bafb86.

Label changes

Label changes:

• add P2: This is a normal tray UX bug with clear source evidence and limited blast radius.
• add impact:other: The issue affects user-visible notification history/discoverability in the OpenClaw tray UI, which is outside the more specific owned impact labels.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal tray UX bug with clear source evidence and limited blast radius.
• impact:other: The issue affects user-visible notification history/discoverability in the OpenClaw tray UI, which is outside the more specific owned impact labels.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore

What I checked:

• Notifications page source: NotificationsPage binds to AppNotificationService and renders only snapshot.ActiveNotifications, so toast-only events cannot appear in the tab. (src/OpenClaw.Tray.WinUI/Pages/NotificationsPage.xaml.cs:25, 4e7982bafb86)
• Toast paths bypass app notifications: Node pairing and system.notify examples call ToastService.ShowToast without a matching AppNotificationService.Show call. (src/OpenClaw.Tray.WinUI/App.xaml.cs:2248, 4e7982bafb86)
• Gateway notification path is toast-only: OnGatewayNotificationReceived stores gateway history and shows a Windows toast, but does not add an AppNotification for the Notifications tab. (src/OpenClaw.Tray.WinUI/App.xaml.cs:2601, 4e7982bafb86)
• Callsite count check: Current main has 24 ToastService.ShowToast callsites in App surfaces and only 2 _appNotificationService.Show callsites, both in the local exec-approval flow. (src/OpenClaw.Tray.WinUI/App.xaml.cs:2287, 4e7982bafb86)
• Feature history: The in-app notification surface was introduced by merged PR Add app notifications surface #748 for local command denial notifications, not as a general toast mirror. (src/OpenClaw.Tray.WinUI/Services/AppNotificationService.cs:129, 06ed71f3c01f)
• Canonical search: The closest merged related PR, Fix chat session routing from Sessions page and toast notifications #611, fixed chat toast session routing but did not solve toast-to-Notifications-tab mirroring.

Likely related people:

• RBrid: Authored the merged app notifications surface and the current inline exec-approval app notification flow that owns the affected service/page wiring. (role: feature owner; confidence: high; commits: 06ed71f3c01f, 4e7982bafb86; files: src/OpenClaw.Tray.WinUI/Services/AppNotificationService.cs, src/OpenClaw.Tray.WinUI/Pages/NotificationsPage.xaml.cs, src/OpenClaw.Tray.WinUI/App.xaml.cs)
• QQSHI13: Authored the merged chat toast routing work that recently touched OnGatewayNotificationReceived and should be preserved by any notification-dispatch refactor. (role: adjacent recent contributor; confidence: medium; commits: 6283fb174ead; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/App.ToastActivation.cs)

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.

[clawsweeper]

🦞⚠️
Automatic implementation stopped before completion.
Reason: The automatic implementation worker stopped before all deterministic gates completed. Open the workflow run for the exact blocker.
Worker: https://github.com/openclaw/clawsweeper/actions/runs/28151879982

Automatic implementation progress:

• State: Planning
• Detail: Codex is reading the issue and repository, choosing an implementation, and planning validation.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/28154339180
• Updated: 2026-06-25T07:33:20.218Z
• Opt out: add clawsweeper:manual-only or clawsweeper:human-review.

[shanselman]

@RBrid this is cool, can you look into this?