Repository navigation
<
10000
link rel="modulepreload" href="https://github.githubassets.com/assets/90-cf0684c4a30f613d.js" crossorigin="anonymous" />
Activity
feat(integration): ask before writing to ~/.claude; fix stale icon an…
amirlehmam commentedon Jul 31, 2026
Found it, and it was a real bug — not the icon cache I initially assumed. Fixed in v0.40.0.
The titlebar one (your second screenshot)
src/renderer/assets/logo.pngwas a copy of the app icon, and the 0.37.0 rebrand updated every shipped asset except that one. So the app was showing its own previous logo back at you, from a file that had been quietly stale for three releases. Everything else —resources/icon.png,resources/icons/icon.ico, the SVG sources — was correct, which is why notifications looked right. One file, missed.The fix is not to re-sync the copy. The copy was the bug: a duplicated asset is a thing that can go stale, and it did. The titlebar now imports
resources/icons/icon-small.svgdirectly, so there is one file and no second copy to drift. Incidentally that variant is the right one for the job anyway — it is drawn for ≤32px, which is exactly the size the titlebar renders at, and it drops the>_prompts that turn to mush down there. It also inlines as a 2.5 KB data URI, replacing a 452 KB PNG that was being squeezed from 1024px into 32 CSS pixels.The taskbar one (your first screenshot)
Two things, and I am confident about the first and honest about the second.
The window icon was a single 512px PNG. Windows asks for that icon at four sizes — 16px in Alt-Tab, 24–32px on the taskbar button, 48px in the window list, 256px in Task Manager — and one 512px representation means the shell downsamples for all of them. The
.icohas purpose-drawn entries at each size (there is a separate tiny variant for 16–24px that keeps only the gradient frame and a big W, because the four-pane cross plus the W-on-a-disc turns into a grey lump at 16 device pixels). wmux now ships the.icoalongside the.pngand hands Windows that instead, falling back to the PNG if it is missing.The shell icon cache is the rest of it. wmux installs to the same path every update, and Windows caches shell icons per path in
iconcache_*.db. So the pinned shortcut, the desktop shortcut and the Start-menu entry can all keep drawing the icon of the version they replaced, while the app's own window icon and its notifications — which Electron loads from disk at runtime — update immediately. That split is precisely the "notifications show the new icon, taskbar does not" you reported. The NSIS installer now runsie4uinit -showand-ClearIconCacheon install to make the shell re-read them.If v0.40.0 still shows the old icon on a pinned taskbar button specifically, that is the cache being stubborn about a shortcut you created before the fix: unpin and re-pin, and it will pick up the new one. A fresh pin will be correct from the start.
Thanks for the screenshots — the fact that notifications were right and the taskbar was wrong is what made this findable. If they had both been wrong I would have gone looking in the build pipeline and found nothing, because the build pipeline was fine.
build: enforce that resources/ copies match their sources (#168, #169)
feat(brand): adopt the new wmux mark across every icon surface
fix(installer): notify the shell about the icon change, since ie4uini…
amirlehmam commentedon Aug 19, 2026
Reopening: the fix this was closed on cannot work, and 1.5.1 is the release that made it measurable.
customInstallinbuild/installer.nshranie4uinit.exe -showand-ClearIconCache. On a machine that had just taken 1.5.1:iconcache_*.dbstill carried its timestamp from the previous day — not one had been rewritten;That last split is the tell, and it's the one this issue originally described.
getAppIcon()readsresources/icon.icofrom disk at runtime, so the window icon updates immediately; the shell-cached surfaces do not.The cause is structural rather than a wrong flag: those databases are memory-mapped by the running
explorer.exe, which only flushes them on shutdown, so no external process can invalidate them while it lives. Killing Explorer and deleting the files was the only thing that fixed it here — and an installer must not do that silently.What changed (4b6fe3f):
customInstallnow callsSHChangeNotify(SHCNE_ASSOCCHANGED), which asks the shell to re-query icons instead of trying to evict a file it doesn't own. Verified as far as it can be without a stale cache to reproduce against: it compiles under the bundled makensis, and run from a silent probe installer it returnslasterror=0.ie4uinitis kept underneath as a cheap hedge.Known remaining gap, stated rather than hidden: this will not refresh a shortcut pinned to the taskbar. That bitmap lives in the taskband store keyed on the AppUserModelId (
com.wmux.app), and only an Explorer restart or an unpin/repin clears it. It heals by itself at the next sign-out, since Explorer rewrites the cache as it exits.If you're on 1.5.1 and still see the old icon, either sign out and back in, or run:
A regression test (
tests/unit/installer-icon-refresh.test.ts) now asserts the mechanism stays wired, because the failure mode here was never "the fix breaks" — it was "the fix quietly stops being connected and nobody notices for releases". Its assertions were checked against the pre-fix file and all three fail there.