[GH-ISSUE #513] Automatically adapt appearance (light/dark) to that of the system #135

New issue

Open

opened 2026-03-02 23:44:47 +03:00 by kerem · 2 comments

kerem commented

2026-03-02 23:44:47 +03:00

Owner

Originally created by @ccjmne on GitHub (Jan 11, 2026).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/513

Hey folks,
I'd like to have OpenCode look bright during the day and dark at night.

I already played around with similar features in Ghostty, tmux, Neovim and I monkey-patched the code base tonight, I can attest to its fairly straightforward, and even simple feasibility.

However, there's still a few other topics I haven't begun considering:

desirability: would you agree it'd be a nice thing to have?
configuration: I can make "the thing", but I haven't even looked at or begun thinking of how we'd let the user toggle that behaviour on and off.
testability: I have in particular no idea about the React and Solid bits, nor about testing in this project in general nor for that feature in particular. I'd have to enlist the LLM for support on that front, but I'd do it responsibly (if I can't understand precisely what it does and subsequently own it, I'd rather offer nothing and ask for help). I can however already commit to copious manual testing ;)

My idea

My plan would be to emit a CSI sequence ? 2031 h when this "automatic appearance toggle" mechanism would be turned on, and listed for the DECSET, DECRST status reports through 997. It's what modern terminal emulators, multiplexers and TUIs use.

A short and clear overview of the principles that go into implementing such support (as well as a table outlining the adoption state across the most prominent terminal tools) is available at https://contour-terminal.org/vt-extensions/color-palette-update-notifications.

TL;DR:

I implemented some proof of concept on my end, which works splendidly; now I'm thinking of contributing upstream and figured, from the first line of the CONTRIBUTING guidelines, that I should start a conversation here before anything.

So here it goes: what do you think? If we want it, I'll get started with making it work and making it configurable.

Originally created by @ccjmne on GitHub (Jan 11, 2026). Original GitHub issue: https://github.com/anomalyco/opentui/issues/513 Hey folks, I'd like to have OpenCode look bright during the day and dark at night. I already played around with similar features in Ghostty, tmux, Neovim and I monkey-patched the code base tonight, I can attest to its fairly straightforward, and even simple feasibility. However, there's still a few other topics I haven't begun considering: - desirability: **would you agree it'd be a nice thing to have?** - configuration: I can make "the thing", but I haven't even looked at or begun thinking of how we'd let the user toggle that behaviour on and off. - testability: I have in particular no idea about the React and Solid bits, nor about testing in this project in general nor for that feature in particular. I'd have to enlist the LLM for support on that front, but I'd do it responsibly (if I can't understand precisely what it does and subsequently own it, I'd rather offer nothing and ask for help). I can however already commit to copious manual testing ;) **My idea** My plan would be to emit a `CSI` sequence `? 2031 h` when this "automatic appearance toggle" mechanism would be turned on, and listed for the `DECSET`, `DECRST` status reports through `997`. It's what modern terminal emulators, multiplexers and TUIs use. A short and clear overview of the principles that go into implementing such support (as well as a table outlining the adoption state across the most prominent terminal tools) is available at https://contour-terminal.org/vt-extensions/color-palette-update-notifications. **TL;DR:** I implemented some proof of concept on my end, which works splendidly; now I'm thinking of contributing upstream and figured, from the first line of the `CONTRIBUTING` guidelines, that I should start a conversation here before anything. So here it goes: what do you think? If we want it, I'll get started with making it work and making it configurable.

kerem added the

feature

core

labels

2026-03-02 23:44:47 +03:00

kerem commented

2026-03-02 23:44:48 +03:00

Author

Owner

@kommander commented on GitHub (Jan 12, 2026):

2031 is general color scheme updates, right? In terminal.zig it already tries to detect that capability. I would activate/deactivate it there in enableDetectedFeatures and resetState respectively. In renderer.ts I would then add an input handler when it is supported, which can emit a color-sheme-changed event or something similar. It can then fetch bg/fg terminal palette colors and check if they flipped, to additionally emit and dark/light mode event.

If you have a better idea, go for it. Happy to bring this in.

@kommander commented on GitHub (Jan 12, 2026): `2031` is general color scheme updates, right? In `terminal.zig` it already tries to detect that capability. I would activate/deactivate it there in `enableDetectedFeatures` and `resetState` respectively. In `renderer.ts` I would then add an input handler when it is supported, which can emit a `color-sheme-changed` event or something similar. It can then fetch bg/fg terminal palette colors and check if they flipped, to additionally emit and dark/light mode event. If you have a better idea, go for it. Happy to bring this in.

kerem commented

2026-03-02 23:44:48 +03:00

Author

Owner

@ccjmne commented on GitHub (Jan 21, 2026):

Hey @kommander,
I am dealing with some personal emergency and haven't spent any more time looking into this, but I still firmly intend to put something together in some near future.

I think it can be even simpler than what you're describing, in the sense that we could, by "subscribing" to the colour scheme updates, to the CSI pattern 997 used to denote specifically whether the environment is in dark or light mode, so we wouldn't even have to implement any sort of heuristic to determine what constitutes a "dark" palette.

In any case, I just wanted to let you know that I haven't yet quite disappeared (well, I have, but not forever) and to thank you for your interest and support!

@ccjmne commented on GitHub (Jan 21, 2026): Hey @kommander, I am dealing with some personal emergency and haven't spent any more time looking into this, but I still firmly intend to put something together in some near future. I think it can be even simpler than what you're describing, in the sense that we could, by "subscribing" to the colour scheme updates, to the `CSI` pattern `997` used to denote specifically whether the environment is in `dark` or `light` mode, so we wouldn't even have to implement any sort of heuristic to determine what constitutes a "dark" palette. In any case, I just wanted to let you know that I haven't yet quite disappeared (well, I have, but not forever) and to thank you for your interest and support!

kerem referenced this issue

2026-03-02 23:45:55 +03:00

[PR #135] [MERGED] fix: reinitialize console capture on global console restore #315

kerem referenced this issue

2026-03-14 09:18:05 +03:00

[PR #135] [MERGED] fix: reinitialize console capture on global console restore #1096