Repository navigation
SysManager 1.109.4
[1.109.4] - 2026-09-17
Saving a second maintenance schedule quietly threw away the first. Scheduled Maintenance keeps one
schedule, by design — it is what makes it safe to set up without administrator rights and impossible for it
to disturb anything else Windows has scheduled. But nothing on the page said so. Pick an action and a time,
press Save, and the schedule you already had was gone, with the tab then reporting the new one as though
nothing had happened. The page now says there is one schedule, and the confirmation says plainly that Save
is replacing the existing one and when that one was next due.
Fixed
- The Scheduled Maintenance page states that there is one schedule, in the header and again beside the
Save button, where the wording changes to "saving this replaces the one above" as soon as a schedule
exists. Previously the only hint was the header's passing mention of "one Windows scheduled task", which
reads as an internal detail rather than a limit that affects you. - The confirmation before saving now asks the question that matches what the button will do. One text
served both cases and described only the first: "This creates a Windows scheduled task" appeared while
about to overwrite an existing one, so the dialog whose whole purpose is to stop an unwanted change hid
which change it was. Replacing now says so in those words and names the time the old schedule was next
due, so you can tell which one you are about to lose.
Changed
- Scheduled Maintenance keeps exactly one schedule, and that is now a stated decision rather than an
unstated limit. Supporting several was considered and deliberately not done: the whole design rests on
touching exactly one Windows task by name, which is what keeps it from needing administrator rights and
what makes it incapable of disturbing anything else on the machine.
Verify the download
Get-FileHash .\SysManager-v1.109.4.exe -Algorithm SHA256Expected SHA256: 2FD006F4CA1329C3C85EFE06B396E29F11C9EC4E4F8BF717710DAFEC5F956317
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.109.4.exe --repo laurentiu021/SystemManagerThat 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.109.4.sbom.json, a CycloneDX inventory of
every dependency resolved for this build.