The supported call pattern
terminal / powershell
$a = New-ScheduledTaskAction -Execute 'pwsh.exe' -Argument '-File C:\Users\you\script.ps1'
$t = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
Register-ScheduledTask -TaskName 'MyWeeklyTidy' -Action $a -Trigger $tRegistration under the current user's context is unprivileged when the task runs as you and touches only your own hives/files. That's the supported line.
Why your tuning app shouldn't be there anyway
- A tuner fixes settings once; it doesn't need a permanent post. A task that applies tweaks at every logon is either compensating for an installer writing startup entries (fix that instead) or papering over the tool's inability to hold state (fix that instead, or don't ship).
- Vecinity of persistence = detection surface. EDRs rightly inventory scheduled tasks. Your tool's legitimacy shows better when it has nothing to show.
- Bloat ratchet: once the task exists, marketing finds reasons for it — sync, “realtime optimization,” news. The absence of the task is a constraint on both.
ProofTune's position
No scheduled task, no service, no Run entry. The manifest literally can't ask for the privileges a background job would want. (The M2 milestone in the repo gates the installer on a static check of exactly that.)
ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.