You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hot reload external TUI configuration and custom themes #37423
Reconcile external V2 TUI configuration and custom theme file edits while the TUI remains open.
The running Config store reacts when OpenCode itself calls its update API, but external edits to cli.json are only read at startup. Custom theme files are loaded initially and can be rescanned through SIGUSR2, but ordinary file edits are not watched and the signal path is not surfaced clearly.
Acceptance criteria
External cli.json edits update supported reactive settings without restarting the TUI.
Changed, added, and removed custom theme files reconcile the live theme catalog.
Invalid intermediate writes retain the last valid config/theme and recover after the next valid save.
Keybinding changes do not corrupt an in-progress multi-key sequence.
TUI integration tests cover a real external file edit and rendered reactive update.
I’d like to work on this. I plan to add a scoped watcher for the external TUI config and custom theme sources, preserve the last valid state across invalid intermediate writes, and reconcile changed/added/removed themes without restarting the TUI. I’ll also add integration coverage using real file edits, including recovery after an invalid write. Is this still the intended scope, and would a PR be welcome?
Another path that should reconcile the theme catalog: /reload in the TUI.
It reports "Configuration reloaded" but doesn't rescan custom themes — it only calls location.reload on the server, while theme files are discovered on mount and via the SIGUSR2 handler. So adding or editing a file in ~/.config/opencode/themes/ and then running /reload leaves /themes and the rendered colors stale until a restart.
Thanks for writing this up. I checked current dev (77a0fd6) and the code works the way the issue describes: cli.json is read once at startup (packages/cli/src/config/config.ts) and only changes when OpenCode calls its own update API. Custom themes in packages/tui/src/context/theme.tsx are loaded at startup and rescanned only on SIGUSR2 (createThemeSource().subscribeRefresh). Neither has a file watcher.
Since nothing here is broken, I haven't treated it as a bug to reproduce. The acceptance criteria describe new work: file watching, keeping the last valid config or theme when a write is invalid, keeping in-progress keybinding sequences intact, and integration tests. It fits better as a planned enhancement than as a bug report.
Activity
philo-x commentedon Aug 29, 2026
I’d like to work on this. I plan to add a scoped watcher for the external TUI config and custom theme sources, preserve the last valid state across invalid intermediate writes, and reconcile changed/added/removed themes without restarting the TUI. I’ll also add integration coverage using real file edits, including recovery after an invalid write. Is this still the intended scope, and would a PR be welcome?
rhighs commentedon Sep 24, 2026
Another path that should reconcile the theme catalog:
/reloadin the TUI.It reports "Configuration reloaded" but doesn't rescan custom themes — it only calls
location.reloadon the server, while theme files are discovered on mount and via the SIGUSR2 handler. So adding or editing a file in~/.config/opencode/themes/and then running/reloadleaves/themesand the rendered colors stale until a restart.Reproduced on 2.0.16 (macOS, tmux).
opencodejr commentedon Oct 28, 2026
Thanks for writing this up. I checked current
dev(77a0fd6) and the code works the way the issue describes:cli.jsonis read once at startup (packages/cli/src/config/config.ts) and only changes when OpenCode calls its ownupdateAPI. Custom themes inpackages/tui/src/context/theme.tsxare loaded at startup and rescanned only onSIGUSR2(createThemeSource().subscribeRefresh). Neither has a file watcher.Since nothing here is broken, I haven't treated it as a bug to reproduce. The acceptance criteria describe new work: file watching, keeping the last valid config or theme when a write is invalid, keeping in-progress keybinding sequences intact, and integration tests. It fits better as a planned enhancement than as a bug report.