[Filed by Copilot on behalf of @bghgary]
Disabling a scheduled workflow does not survive an app restart. On every launch the app writes enabled back to true — leaving next_run_at null, so the row shows as enabled in the UI while the scheduler never considers it due. Re-disabling is undone by the next launch, and the workflow tool surface has no delete, so the only durable remedy is deleting it in the UI.
Three occurrences in 17 hours on one machine, app 1.1.10 and 1.1.11.
It is the app's own startup path
workflows.updated_at after each flip, against the app process's first log line:
| flip |
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 |
Four app starts occurred in the window; the workflow was disabled across three of them and re-enabled by all three.
No client could have written it: the 08-19 write landed 816 ms before that process began listening on its WebSocket (23:09:12.227Z), so no renderer or CLI session had a transport yet. Between the 08-19 and 08-20 restarts the app ran ~20 hours continuously, and six reads of the workflow list all returned enabled: false with an unchanged updated_at.
Not the schema migration that shipped with 1.1.11: the 08-19 restart ran the same version as the process before it, applied no migration, and still re-enabled the row 6 ms after opening data.db.
The write is unlogged — the workflow's id appears nowhere in any app log — and touches only the disabled row; enabled workflows keep their updated_at across the same restart.
Where to look
An enable through save_workflow populates next_run_at. Both startup re-enables left it null. So the startup path appears to set enabled = 1 without going through the code that arms the schedule, which is also why the row is inert afterwards.
Reproduction
- Create a scheduled workflow with a cron expression.
- Disable it.
- Quit and relaunch the app.
- It is enabled again, with no next run time.
Every disable here went through the save_workflow tool rather than the Workflows UI; worth checking whether a UI disable behaves the same.
Limits
The re-enabled workflow never actually ran — with next_run_at null the scheduler never found it due — but each episode was caught within five minutes against a */30 cron, so none spanned a firing slot. Only one workflow was ever left disabled across a restart, so the sample is one row.
Environment
Copilot desktop app 1.1.10 (a7315e1) and 1.1.11 (0155271), Copilot CLI 1.0.80, Windows 11 build 26310.
[Filed by Copilot on behalf of @bghgary]
Disabling a scheduled workflow does not survive an app restart. On every launch the app writes
enabledback to true — leavingnext_run_atnull, so the row shows as enabled in the UI while the scheduler never considers it due. Re-disabling is undone by the next launch, and the workflow tool surface has no delete, so the only durable remedy is deleting it in the UI.Three occurrences in 17 hours on one machine, app 1.1.10 and 1.1.11.
It is the app's own startup path
workflows.updated_atafter each flip, against the app process's first log line:2026-08-19T23:09:11.411Z23:09:11.405v1.1.102026-08-20T19:03:19.124Z19:03:19.025v1.1.11Four app starts occurred in the window; the workflow was disabled across three of them and re-enabled by all three.
No client could have written it: the 08-19 write landed 816 ms before that process began listening on its WebSocket (
23:09:12.227Z), so no renderer or CLI session had a transport yet. Between the 08-19 and 08-20 restarts the app ran ~20 hours continuously, and six reads of the workflow list all returnedenabled: falsewith an unchangedupdated_at.Not the schema migration that shipped with 1.1.11: the 08-19 restart ran the same version as the process before it, applied no migration, and still re-enabled the row 6 ms after opening
data.db.The write is unlogged — the workflow's id appears nowhere in any app log — and touches only the disabled row; enabled workflows keep their
updated_atacross the same restart.Where to look
An enable through
save_workflowpopulatesnext_run_at. Both startup re-enables left it null. So the startup path appears to setenabled = 1without going through the code that arms the schedule, which is also why the row is inert afterwards.Reproduction
Every disable here went through the
save_workflowtool rather than the Workflows UI; worth checking whether a UI disable behaves the same.Limits
The re-enabled workflow never actually ran — with
next_run_atnull the scheduler never found it due — but each episode was caught within five minutes against a*/30cron, so none spanned a firing slot. Only one workflow was ever left disabled across a restart, so the sample is one row.Environment
Copilot desktop app 1.1.10 (
a7315e1) and 1.1.11 (0155271), Copilot CLI 1.0.80, Windows 11 build 26310.