Skip to content

v0.2.4 — Bypass WinRT COM adapter bug breaking toast notifications

Choose a tag to compare

View all tags
@Nickdevcode Nickdevcode released this 26 May 05:39
v0.2.4
9f2da8e

v0.2.4 — Bypass WinRT COM adapter bug breaking toast notifications

🏷️ Note: this tag was created retroactively from commit 9f2da8e to align the GitHub release history with the [0.2.4] entry that already existed in CHANGELOG.md. The fix below is also included in v0.3.0 — if you're on v0.2.x and just want this specific fix without the v0.3.0 breaking changes (legacy system removal), you can pin to ringly@0.2.4.

This release fixes a critical Windows 11 / PowerShell 5.1 bug that caused toast notifications to be silently dropped, even when everything else looked correctly configured.

Fixed

  • Silently blocked notifications on Windows 11 / PowerShell 5.1. On several setups — especially Claude Code installed via global npm with the AUMID registered through a shortcut — the toast never appeared visually; only a short beep played. Root cause: a known PowerShell bug (PowerShell#9816) where WinRT objects implement IInspectable but not IDispatch. As a result, $notifier.Setting returned a mis-typed enum when compared with [NotificationSetting]::Enabled or concatenated into a string. The comparison silently produced a false-positive BLOCKED: classification with an empty reason (visible in logs as BLOCKED: with nothing after the colon), aborting Show() before the toast could fire.

    The check now reads $notifier.Setting.value__ — the intrinsic backing field of any .NET enum, accessed directly without going through the broken COM adapter — and compares against integer 0 (Enabled). If the read fails for any reason, the code falls through to Show() rather than block; any real error surfaces via the catch with a meaningful message instead of a phantom block. Non-zero values are mapped to readable reasons (DisabledForApplication, DisabledForUser, DisabledByGroupPolicy, DisabledByManifest).

  • Removed the [Console]::Beep(800, 200) fallback on the blocked path. That short beep was being emitted whenever the check false-positived and misled users into thinking the notification had actually arrived — when in fact it was just the beep. When the toast is genuinely blocked by system configuration, the CLI now returns BLOCKED: with a readable reason and emits no sound.

Tests

  • +14 new tests in test/psTemplates.test.ts covering the new robust check, the reason mapping, the absence of the misleading beep, and single-quote escaping in AUMID, XML, and shortcut path.

Upgrade notes

  • If you've been seeing the "short beep but no toast" symptom on Windows 11, upgrade to v0.2.4 (or v0.3.0+). The fix is purely platform-level — no config or migration needed.
  • If you want the modernized v0.3.0 (security hardening, atomic writes, legacy removal) and not just this fix, jump straight to v0.3.0.

Full changelog: v0.2.3...v0.2.4

Assets 2
Loading