SysManager 1.130.81

[1.130.81] - 2026-10-23

Right-click Menu's switches now match what Explorer does: an add-on listed for both files and folders switches as
one, one blocked for your account shows as off, turning an entry back on leaves nothing behind, and a preset leaves
Windows' File ownership entries on.

Fixed

• Switching off an add-on's Files row took it off folders too, while its Folders row still said On. Windows
  blocks an add-on everywhere at once, but only the row you clicked changed, and the counts with it, until a
  Refresh. The add-on's other rows now switch with it. Since 1.102.0.
• An add-on blocked for your account only showed as on. Windows also reads a per-user list of blocked add-ons,
  which other tools write, and the tab read only the machine-wide one, so the add-on stayed out of the menu while
  its switch said On, and switching it off and on again changed nothing. That list is read now, and switching the
  add-on back on clears it there too, which needs no administrator rights. Since 1.102.0.
• Turning an entry back on could leave a key behind, and switching off one that was gone reported success. For
  an entry Windows protects, the switch hides it with a key for your account only, and turning it back on kept
  that key, which outlived the program's own entry once the program was uninstalled. It is removed now once it
  holds nothing else. Switching off an entry whose key was gone created a key for it and said it had worked; it now
  says it could not, and turning such an entry on works. Since 1.16.0.
• Win10 Default and Win11 Default switched off Windows' own File ownership entries. Windows labels them with a
  text from one of its own files rather than a plain name, which the tab did not read, so they counted as
  third-party, and no preset turned them back on. They count as Windows' now. Since 1.16.0.

---

Verify the download

Get-FileHash .\SysManager-v1.130.81.exe -Algorithm SHA256

Expected SHA256: 3614FB473BA79D97077934FCF12E66AB1DAC4D6AD5287722538D7E5260982815

This build is not code-signed, so Windows will warn on first launch. That is
expected for a small independent app: see what the warning says and what to
click.
Code signing is planned through the SignPath Foundation,
which provides free certificates to open-source projects, with signing performed by
SignPath.io. Until then, the SHA256 above and the build
attestation below are what establish that a download is the genuine build.

Code signing policy

This release is not code-signed. The team roles, release-approval process and
privacy policy required by the SignPath Foundation programme
are documented in advance under Code signing
policy. That
documentation is a prerequisite for applying, not evidence of a certificate. The
attribution line naming SignPath as the signing provider will appear here once a
certificate is actually issued.

This program will not transfer any information to other networked systems unless
specifically requested by the user or the person installing or operating it. Full
privacy policy.

Verify where this binary came from

This exe was built by GitHub Actions from this public source, and the build is
recorded in the Sigstore public transparency log. With the
GitHub CLI:

gh attestation verify .\SysManager-v1.130.81.exe --repo laurentiu021/SystemManager

That proves which commit and workflow produced this exact binary, something the
SHA256 file cannot show, since it is published alongside the exe it describes.
Each release also ships SysManager-v1.130.81.sbom.json, a CycloneDX inventory of
every dependency resolved for this build.