ospab 732d0bf5ae fix(installer): grant users permission to start the helper task ... The task was registered correctly and pointed at the right binary — the app's own log confirmed the match — but starting it failed: run: schtasks /Run failed (Some(1)): ERROR: Access is denied. falling back to a direct elevated launch — this is the consent prompt Registering a task and being allowed to start one are separate things, and I had conflated them. The principal (BUILTIN\Users by SID, HighestAvailable) decides who the task runs AS. Who may START it comes from the task's security descriptor, and a task created by an elevated installer defaults to granting execution to Administrators only. So the unprivileged GUI was refused and fell back to prompting on every connect, exactly as before the installer existed. This also explains why manual testing said the opposite: running the task by hand happened from an elevated console, where it works, which pointed suspicion at the app for several rounds. Register-ScheduledTask cannot set a descriptor, so the hook now follows the registration with a SetSecurityDescriptor call through the Task Scheduler COM object: GA for Administrators and SYSTEM, GR+GX for BUILTIN\Users. A failure there is reported on its own rather than being folded into the success message, since the task would otherwise look registered while remaining unusable.		2026-08-11 23:28:36 +03:00
..
hooks.nsh	fix(installer): grant users permission to start the helper task	2026-08-11 23:28:36 +03:00