Disabled scheduled workflow is re-enabled on app startup without a next run time

[bghgary]

[Filed by Copilot on behalf of @bghgary]

Affected version or release

v1.1.10 (a7315e1) and v1.1.11 (0155271)

Installation context

Local Windows desktop app; one scheduled workflow created and disabled through the app's agent tool surface.

What happened?

Disabling a scheduled workflow does not survive an app restart. Each launch changes its stored enabled value back to true but leaves next_run_at null. The UI therefore shows the workflow as enabled while it never becomes due.

This happened three times in 17 hours on one machine. The stored update followed the app process's first log line by 6 ms on v1.1.10 and 99 ms on v1.1.11:

Stored update	Process start	Delta
2026-08-19T23:09:11.411Z	23:09:11.405 v1.1.10	+6 ms
2026-08-20T19:03:19.124Z	19:03:19.025 v1.1.11	+99 ms

No renderer or CLI session had a transport when the first update occurred: it preceded the process listening on its WebSocket by 816 ms. While the app then remained running for about 20 hours, six workflow-list reads all returned enabled: false with an unchanged updated_at.

The v1.1.10 relaunch used the same version as the preceding process and logged no migration, so this was not introduced by the v1.1.11 schema migration. Only the disabled row's updated_at changed; enabled workflows preserved their timestamps across the same launches.

Enabling through save_workflow normally populates next_run_at; both restart flips left it null. The timing and stored state point to startup handling, but the app source is not public, so that path is inferred rather than code-confirmed.

Steps to reproduce

1. Create a scheduled workflow with a cron expression.
2. Disable it through save_workflow.
3. Quit and relaunch the app.
4. Observe that it is enabled again but has no next run time.

Expected behavior

The workflow remains disabled across app restarts.

Additional context

• Windows 11 build 26310.
• The re-enabled workflow never ran. Each occurrence was caught within five minutes against a */30 cron, so none spanned a firing time.
• Every disable in this sample used save_workflow; disabling through the Workflows UI was not tested.
• Only one disabled workflow was observed across restart.
• Workflows marked removed/manual persist in UI after restart; no supported hard-delete or purge path Body #1158 is related, but it covers manual/removed workflows remaining visible and the missing delete path rather than this disabled-to-enabled state change.