Software 45021 Published by

Open-Shell released build 4.4.202 to its nightly channel today, a security- and stability-focused pre-release containing nine scoped fixes but no major new features. Most significant are two memory-safety fixes, a use-after-free and an out-of-bounds write, both verified with an ASan/UBSan harness. The bulk of the build was authored by first-time contributor @YellowNest, mentored by lead maintainer ge0rdi. The one visible enhancement is dark mode for the Classic Explorer toolbar, part of a community project that now ships signed binaries and ARM support while competing against paid tools like StartAllBack and Start11.



Open-Shell Ships 4.4.202 Nightly, a Security-Focused Update With a Single New Feature

The community fork of Classic Shell pushed build 4.4.202 to its nightly channel today, and you might well scroll right past it. There are no new features. Just nine tightly scoped fixes, one safer installer, and a single dark-mode tweak. That's the point, really.

It's what a mature, volunteer-run utility looks like a decade into its life. Open-Shell keeps Windows 7, 8, 8.1, 10, and 11 users from having to embrace Microsoft's modern Start menu, and this build is entirely about keeping that promise without breaking anything along the way.

The real story, though, is who wrote it.

Openshell4

A first-timer did most of the work

@YellowNest made their debut pull request in this very release cycle and ended up authoring nearly every change in 4.4.202. Lead maintainer ge0rdi (Richard) reviewed, merged, and co-authored the one feature commit.

Open-Shell has over 9,000 GitHub stars and roughly 513 forks now. It's a volunteer operation carrying a multi-million-user install base, and builds like this show the handoff between founders and newcomers actually works.

Two memory-safety fixes you won't see but should care about

The most important parts of 4.4.202 are invisible. They live in the plumbing rather than the menu.

YellowNest fixed two memory-lifetime bugs, and PR #2550 ships with a write-up more rigorous than most community projects ever get around to. The use-after-free is the nastier one. The icon cache is saved to disk by a background thread that snapshots raw pointers under a read lock, releases the lock, then re-checks each pointer much later. Between those two steps, cleanup routines can erase the very entries whose pointers were saved. Classic heap use-after-free: the writer touches memory that's already gone.

The fix snapshots entries while the lock is still held and makes ClearCache() wait for any in-flight save. YellowNest proved it with a C++20 ASan/UBSan regression harness that deterministically reproduced the original bug, then ran 2,000,000 randomized entry combinations with zero behavioral difference. Worth flagging: there's no user-reported crash tied to this. It's defensive hardening, not incident response, which is honestly the better reason to ship it.

The out-of-bounds write is more straightforward. Painting a user-supplied background image onto the menu bitmap wasn't being clipped, so writes could run past the allocated buffer. The fix clips those writes to valid bounds. Close the hole, avoid corrupting memory or crashing the menu.

The feature, and the safety net

If you want to count it, the one feature is dark-mode support for the Classic Explorer toolbar, tooltip, rebar, and status bar. It started out as @DartVanya's work back in issue #361. YellowNest ported and hardened it, ge0rdi co-authored, and the commit notes plainly that "toolbar locking remains separate." You can tell from that this was a deliberate, scoped change rather than a sweeping redesign.

Then there's the installer. If the setup process ever leaves Windows Explorer stopped, build 4.4.202 now restarts it after installation completes. For a program whose entire reason for being is hooking deeply into the shell, a botched install that strands you in front of an empty desktop is a proper horror story. This meaningfully lowers the cost of a failed install.

Where it fits in the bigger picture

Keep in mind that this build doesn't exist in a vacuum. Open-Shell started digitally signing its binaries with SignPath.io back at 4.4.199 and 4.4.200 in July 2026, so installs no longer trip SmartScreen warnings the way they did for years. It's also carried Windows on ARM compatibility since 4.4.196, though installing anything older on ARM hardware can leave you unable to log in after a reboot, so the project tells you to stay past that number.

It competes in a crowded space. StartAllBack runs about $4.95 and pairs an older Start menu with taskbar restoration. Start11 from Stardock tries to make Windows 11 feel like 10 or 7 across the board. ExplorerPatcher is free and open-source but carries more trouble after Windows updates. The general consensus among power users is that Open-Shell's Start menu is simply the best for pure menu functionality, and free. It does the menu and deliberately nothing more, so if you want a classic taskbar too you'll need to layer something on top.

It's a bit of a strange situation. You're getting genuinely solid engineering, ASan-verified memory fixes, code signing, a first-time contributor doing the bulk of a release, for nothing, from a project that keeps having to adapt to a menu Microsoft refuses to stop changing. The lack of a polished taskbar tweak hurts for some, sure. However, at the same time, free plus reliable is a hard combination to argue with.

Grab it, if you want it

Head here to the Open-Shell GitHub page to pull build 4.4.202 off the nightly channel. Expect this cadence to continue: small, targeted releases, since Windows 11's shell keeps shifting and forces constant adaptation. As of right now, 4.4.202 is the freshest build in that line.