[Bug]: Disabling a provider is irreversible from the UI — provider vanishes from the AI Providers list, and runtime-opencode-config.json edits are silently overwritten

Summary

Disabling a provider in Settings → AI Providers is a one-way door. The list renders only enabled providers, so disabling one removes it from the very list holding its toggle. There is no UI path back.

The obvious recovery is also a trap. ~/.config/openwork/runtime-opencode-config.json holds disabled_providers and reads as the source of truth, but it is regenerated at launch from runtime.sqlite. Edits apply, survive until relaunch, then silently revert — no error, no log line.

Environment

• OpenWork 0.18.46, opencode 1.18.30
• macOS 27.0, arm64
• Local/host mode, not signed into OpenWork Cloud

To Reproduce

1. Configure a working local provider (mine: azure in ~/.config/opencode/opencode.json with options.resourceName, key in auth.json). Confirm models list and a request succeeds.
2. Settings → AI Providers → disable it.
3. It disappears from the AI Providers list.
4. No way to re-enable: no greyed row, no "show disabled" filter, absent from the model picker.
5. Restart and start a new session. Still gone.

Expected behavior

Disabled providers stay listed in a disabled state with an operable toggle, so the action is reversible.

Actual behavior

The provider is filtered out of the list; the only recovery is editing SQLite by hand.

Where the state lives

• Authoritative: runtime.sqlite → runtime_opencode_configs → row __openwork_engine_global__ → config_json.disabled_providers
• Generated: ~/.config/openwork/runtime-opencode-config.json, rewritten from that row at launch

Workaround

sqlite3 ~/.config/openwork/runtime.sqlite \
  "select config_json from runtime_opencode_configs;"

Remove the provider ID from disabled_providers, write the row back, then fully quit and relaunch. Editing the JSON file alone does nothing.

Secondary issue: the silent overwrite

Independent of the UI gap, a user-editable-looking JSON config being clobbered from a database with no warning is its own problem. Either mark the file as generated (header comment or a .generated suffix), or have the loader detect drift and reconcile rather than overwrite.

Suggested fix

Render disabled providers in the AI Providers list greyed-out rather than filtering them out. The list is likely built from the resolved provider set, which drops disabled entries upstream, so disabled_providers IDs probably need merging back in before render.

Related

• #2342 — same store-vs-file bug class, for MCPs; touches userRuntimeConfigFromOpencodeConfig, which already reads disabled_providers
• #1799 — inverse case (provider re-enables when the user wants it off)
• #3993 — automation fails when the configured provider is disabled
• #4922 — Azure resourceName on the managed-catalog path; distinct from this