Repository navigation
Windows: desktop notifications can never be enabled — "Desktop notifications are blocked. Enable them in your system settings." #2445
Description
Summary
On Windows, enabling Settings → Notifications → Desktop alerts always fails with
"Desktop notifications are blocked. Enable them in your system settings." — even on a
fresh install where the OS has never been asked for permission. There is nothing to
enable in Windows Settings: the app never appears in the notifications app list because
it has never posted a toast.
Root cause is an upstream bug in tauri-plugin-notification's injected JS shim
(reported separately: tauri-apps/plugins-workspace#3512), but Buzz's permission flow
turns it into a hard dead end, and a one-line change on Buzz's side works around it.
Environment
- Buzz Desktop 0.4.22 (
Buzz_0.4.22_x64-setup_alpha-unsigned.exe), also present inmain - Windows 11 Home 10.0.26200, WebView2 runtime (Evergreen)
tauri-plugin-notification2.3.3 (perdesktop/src-tauri/Cargo.lock)
Steps to reproduce
- Install Buzz on Windows and complete onboarding.
- Open Settings → Notifications and turn on Desktop alerts.
Expected: toggle turns on; a toast is shown for the next mention/DM.
Actual: toggle snaps back off with the "blocked" error. No OS permission prompt is
shown, and Buzz is absent from Windows Settings → System → Notifications.
Root cause
tauri-plugin-notification injects an init script that replaces window.Notification
with a shim. At startup the shim computes its permission state
(guest-js/init.ts):
async function isPermissionGranted(): Promise<boolean> {
if (window.Notification.permission !== 'default' || __TEMPLATE_windows__) {
return await Promise.resolve(window.Notification.permission === 'granted')
}
return await invoke('plugin:notification|is_permission_granted')
}On Windows __TEMPLATE_windows__ is true, so this always evaluates
window.Notification.permission === 'granted' against the shim's own
freshly-initialized 'default' → false → the bootstrap stamps the permission
denied on every launch, without ever consulting the backend (whose
permission_state() unconditionally returns Granted on Windows).
Buzz then hits this in desktop/src/features/notifications/lib/desktop.ts
(getDesktopNotificationPermissionState), which trusts window.Notification.permission
first, and in desktop/src/features/notifications/hooks.ts (setDesktopEnabled),
which only calls requestDesktopNotificationAccess() when the state is "default".
Since the state is already "denied", the request that would repair it is never made,
and the user is told to fix it in system settings — where there is nothing to fix.
Verification
Attached the live app via the WebView2 CDP endpoint
(WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=9222):
window.Notification.permission → "denied" (tauri shim, fresh launch)
window.Notification.requestPermission() → "granted" (backend happily grants)
window.Notification.permission → "granted" (toggle now works, toasts fire)
So the OS and the plugin backend both allow notifications; only the shim's cached
bootstrap value is wrong.
Suggested fix (Buzz side, until upstream lands)
In setDesktopEnabled (hooks.ts), also attempt the permission request when the
reported state is "denied" on Windows — requestPermission() corrects the shim's
state and returns "granted":
if (nextPermission === "default" || (nextPermission === "denied" && isWindowsPlatform())) {
nextPermission = await requestDesktopNotificationAccess();
setPermission(nextPermission);
}Alternatively, getDesktopNotificationPermissionState could prefer the plugin's
isPermissionGranted() over window.Notification.permission when running under Tauri.
Happy to send a PR for either variant.
Activity
uevuleocha commentedon Aug 15, 2026
Still reproduces on 0.5.14 (Windows 11 Home 10.0.26200). Global toast switch on, no Focus
Assist, 50 other apps registered for notifications, Start Menu shortcut carries the
correct AUMID — and no xyz.block.buzz.app entry exists under
HKCU...\Notifications\Settings.
Negative result worth recording: manually creating that key with Enabled=1 and fully
restarting Buzz does NOT fix it. The settings page renders the same two blocked banners
before and after. That rules out missing OS registration as the root cause and supports
the shim analysis in this report.
jasonbourg-design commentedon Aug 22, 2026
Confirming this on a packaged Windows 11 install of 0.5.18 (previous confirmation
here was 0.5.14), with live measurements from the running WebView2 rather than
inference. This is the real-shell evidence #2483 and #5600 both say they are waiting on.
Environment: Buzz Desktop 0.5.18, Windows 11 Home 10.0.26200, WebView2 Evergreen
151.0.4129.93,
buzz-desktop.exeunsigned build.The OS side is healthy — nothing is blocking anything
HKCU\...\PushNotifications\ToastEnabled=1, no Focus Assist / DND profile.xyz.block.buzz.app.CreateToastNotifier("xyz.block.buzz.app").SettingreturnsEnabled.xyz.block.buzz.appkey underHKCU\...\Notifications\Settings, so Buzz then does appear in Settings → System →Notifications, switched on — and the in-app banners are completely unaffected.
The shim and the backend disagree, measured live
Evaluated in the running app over the WebView2 devtools protocol:
The backend says granted while the shim says denied, which is exactly the
__TEMPLATE_windows__short-circuit described in this issue and in #5600.Requesting permission repairs it, and a real toast arrives
With that value repaired, the settings page immediately renders correctly — both red
banners gone, every switch live — and
new Notification(...)through Buzz's own pathdelivers a real Windows toast. So all three conditions #2483 asks for are met on a
real installation: the request returns
granted, Buzz registers under System →Notifications, and a genuine toast arrives.
The persistence half also reproduces on a real install
Reloading the window (same startup path as a cold launch) gives:
This confirms the
hooks.tseffect quoted in #5600 on a packaged build: the bogusdeniedat mount actively rewrites the user's persisted setting back tofalse. Fixingonly the enable path would leave Windows users re-enabling alerts after every restart,
so the read-path repair in #5600 looks like the necessary half.
One new negative result
In addition to the registry-key dead end already recorded above: granting the
WebView2 content-setting for notifications also does nothing. Adding
to
EBWebView/Default/Preferences(alongside themedia_stream_mic/media_stream_cameragrants that are already there) survives restart but changesnothing — expected in hindsight, since the shim replaces
window.Notificationwholesaleand serves
permissionfrom its own module-level variable, so the underlying WebView2permission is never read. Worth recording so nobody else spends time there.
End-to-end confirmation after working around the shim
With the shim's value repaired, a real agent DM and a real channel @mention both
arrived as native Windows toasts, correctly branded "Buzz" — so once permission is
right, the whole delivery path works and needs no other change.
Workaround for anyone finding this issue
Until a fix ships, patching the single occurrence of
||__TEMPLATE_windows__?to||false&&_TEMPLATE_win?inbuzz-desktop.exemakes the bootstrap fall through tois_permission_granted, which returnstrue. The replacement is the same byte length,and it breaks the template token so the Rust-side
.replace()no longer matches it.On a patched 0.5.18, cold-started with no devtools attached and no intervention, the
settings page comes up with both banners gone and the switches live, Desktop alerts
enables normally, and DMs and mentions notify. I have not yet observed a further
restart, so I can confirm the boot-time repair but not multi-restart persistence.
Obviously a local hack for anyone stuck, not a fix — an app update overwrites it. The
real repair is the read-path change in #5600, which also addresses the
hooks.tsrewrite above.
fix(buzz-docker): add standard Windows Desktop notification workaround
nikeruga commentedon Sep 7, 2026
Windows 0.5.23: Desktop alerts 활성화 차단 재현
Windows Buzz Desktop 0.5.23에서 다음 문제가 발생합니다.
아래 두 안내가 나오며 알림을 활성화할 수 없습니다.
앱이 실행 중일 때 발생하는 문제이므로, X 버튼으로 앱을 종료한 뒤 알림 수신이 중단되는 #2412의 트레이 문제와는 별개입니다.
정상적인 알림 권한 요청이 가능하고, 앱 재실행 후에도 알림 설정이 유지되며, 사용자가 허용한 실제 알림이 Windows에 전달되는 공식 수정 릴리스를 요청합니다. 사용자의 OS 알림 차단·음소거 선택은 존중해야 합니다.
관련 수정안 #7275, #6876과 함께 확인해 주세요. 중복 이슈 대신 이 기존 이슈에 0.5.23 재현 내용을 추가합니다. 감사합니다.
fix(desktop): stop trusting the notification plugin's cached "denied"…
deven298 commentedon Sep 9, 2026
Is this fixed? My team is complaining about missing messages while using Buzz because notifications doesn't work. Also on the phone app we don't get notifications too.
bernhardkaindl commentedon Sep 12, 2026
@deven298:
@salman1993 and @wesbillman, please read the above comments:
This is a 100% real bug which affects 100% of Windows users, not a race condition.
Summary:
fix(desktop): enable Windows-native winrt/toast notifications and make them reliable #7614
for links.
Cc: @baxen for Windows tracking on parent issue
webmanblr commentedon Sep 18, 2026
any update?
fix(desktop): repair the Windows notification shim's false denial on …
wpfleger96 commentedon Oct 9, 2026
🤖 fixed by #5600, which ships in the next desktop release. on Windows the notification plugin reported permission as
deniedat startup without asking the backend, so Buzz refused to turn Desktop alerts on and also saved the setting as off on every launch. #5600 repairs that reading, so the toggle turns on and stays on across restarts. if yours was already forced off, turn Desktop alerts on once after updating. thanks for the reportchore(sync): merge upstream desktop-v0.5.28 (#35)