Set-PSUSetting -DisableAutoReload:$false (-Integrated) has no effect - Auto-reload can't be enabled code-first
Hi,
PSU version: 2026.2.2 (Windows, licensed, ZIP Installation)
What we're trying to do:
Enable the "Auto-reload" toggle (Settings -> Files -> Configuration Changes) programmatically from a code-first script (.universal/settings.ps1), so a freshly provisioned local dev instance or automatically newly deployed instances doesn't need a manual click every time.
Steps to reproduce:
1. Fresh instance, new/empty database (GitSyncBehavior is not OneWay, so the
toggle is available, not greyed out).
2. In .universal/settings.ps1 (a script PSU re-evaluates on every server
start), call:
Set-PSUSetting -DisableAutoReload:$false -Integrated
(also tested without -Integrated)
3. Restart the server (reusing the same database, no DB reset) several times.
Expected: Settings -> Files -> Configuration Changes -> "Auto-reload" toggle shows enabled.
Actual: Toggle stays off across every restart, no matter how many times the script runs with -DisableAutoReload:$false.
Isolating the cause:
- Manually flipping the same toggle ON once via the admin console persists
correctly across subsequent restarts (as long as the DB isn't recreated) -
so DB persistence of the setting itself works fine.
- This suggests Set-PSUSetting -Integrated either doesn't write
DisableAutoReload to the database at all, or writes it but the running
process doesn't pick it up, while the admin console's toggle goes through a
different code path that applies it live.
- Also tried the DisableCodeFirst alias - same result.
Questions:
1. Is this a known bug, or is DisableAutoReload intentionally not settable via -Integrated or code directly?
2. Is there any supported code-first / startup-time way (appsettings.json key, cmdlet, CLI flag) to enable Auto-reload on a fresh instance without a manual admin console click?
3. If not, could this be added as a feature - i.e. Set-PSUSetting actually applying DisableAutoReload live, matching the admin console's behavior?
Happy to provide logs or run further tests if useful.
Thanks,
René
716b4224-396d-469a-b30f-f195c8b06534.png
Hello Mordecai,
Thank you for the detailed reproduction steps and screenshot. The distinction you identified is important: enabling Auto reload through the admin console persists correctly in the same database, while `Set-PSUSetting -DisableAutoReload:$false` does not appear to produce the same result.
At this point, I cannot confirm this as either a known bug or an intentional limitation. I also could not verify a currently documented `appsettings.json` key or CLI argument that provides a supported startup-time alternative.
This requires exact-version validation using the following conditions:
* PowerShell Universal 2026.2.2
* Windows ZIP installation
* Fresh database
* `GitSyncBehavior` not configured as `OneWay`
* `Set-PSUSetting` tested both with and without `-Integrated`
* Comparison against enabling the same setting through the admin console
* Restart using the same database to verify persistence and runtime behavior
The information you have already provided is sufficient for this validation, so no additional logs or public evidence are needed at this stage.
If the behavior is independently reproduced, it would likely be better handled as a Bug Report because an existing cmdlet parameter would not be applying the expected setting state. If the parameter is intentionally unsupported for this setting, then the request for a supported code-first mechanism would be appropriate as a Feature Request. We should confirm the exact behavior before assigning either classification.
Best regards,
Ruben Tapia
Hello Mordecai,
Thank you for the detailed reproduction steps.
I completed an isolated validation using PowerShell Universal 2026.2.2.0 on Windows with the ZIP installation.
The laboratory confirmed a behavioral difference between the administrative console and Set-PSUSetting:
.universal\settings.ps1 executed on every expected startup.
Set-PSUSetting completed without relevant binding errors.
$false, $true, with and without -Integrated, and the DisableCodeFirst alias produced the same result.
The code-first variants did not persist or apply the Auto-reload state.
Enabling Auto-reload through the administrative console persisted after restarting PSU.
The console stored the enabled state per node and subsequent file modifications were detected and processed automatically.
This confirms that the administrative-console toggle and Set-PSUSetting -DisableAutoReload are not applying the same effective state in PSU 2026.2.2.0.
I will escalate the laboratory findings and sanitized reproduction evidence internally to our Development team. They will need to confirm whether the cmdlet behavior is a product defect, an implementation limitation, or whether the parameter is intended to have different semantics from the current Auto-reload toggle.
I will update this thread after we receive a confirmed technical assessment.
Best regards,
Ruben Tapia