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
@adamdotdevin I've recently moved to ghostty and, inside tmux, more of the UI seems to adapt when I change from dark mode to light mode, but the chat input and status bar don't update. Sometimes I even have to quit all opencode sessions, quit ghostty, and then the ui renders correctly
I'm using Ghostty on MacOS Thaoe and have it configured for both light and dark mode. If i change the OS theme from light to dark mode, the terminal will change theme as well. If i run opencode , it will show the same mode - however opencode won't detect OS theme changes when already running. Is it possible to listen for these changes?
Note: i haven't configured theme for opencode but relying on the Ghostty configuration
It is possible, with the caveat that not all terminals support it, but I'll support that event from opentui so opencode will be able to change the theme type automatically.
I've started using the new opentui version of this.
I'm finding that I have to manually switch it to light mode each time I open it.
I'm also using a terminal and custom color scheme which most software is unable to detect as being either light or dark.
I investigated how to fix this in the past and found a solution using an environment variable called COLORFGBG (it's supported by a bunch of terminals and software). So in software I've written in the past I've included a fallback to reading this variable if the normal detection doesn't work. Would you be willing to include that feature in opencode please?
If not; is there some way to change the default from dark to light?
Having it persisted is certainly an improvement. Thank you.
That said; sometimes I switch from light to dark depending on environment (day time office usage vs late night on call work). So improving the detection would be ideal as a future enhancement.
Having it persisted is certainly an improvement. Thank you.
That said; sometimes I switch from light to dark depending on environment (day time office usage vs late night on call work). So improving the detection would be ideal as a future enhancement.
ill also put a repro here.
i have iterm to swap colors on macos appearance change, so light mode has light grey background, and dark mode has black background.
so with that, when i have an iterm window open, and i toggle from light to dark mode, my iterm window changes its colors.
but if i do that while having opencode running, it never changes.
see here. claude, opencode and codex. claude is the only one handling things correctly.
TL;DR: If OpenCode isn't detecting your OS theme changes in tmux, try detaching and re-attaching to your tmux session (then restarting OpenCode if its still open)
After investigation, I've deduced that tmux captures the system theme in some variable on attachment. This is why on my setup (Macbook, Ghostty, Oh-my-tmux, Neovim, Opencode), I have to detach and re-attach to tmux, then restart OpenCode for it to actually get the proper theme.
The reason Neovim automatically switches is because for most people (including me) neovim is set up to check the actual system settings to see if its on dark mode.
But for OpenCode (and even other CLI's like git-delta), the theme data seems to rely on information that tmux captures and updates when the user creates a new session or attaches to an existing session.
I believe that is the key issue. You guys can test this theory. I have tested it rigorously and it has checked out consistently for me.
Interesting, I didn't know about that one. Could work at least for initial detection. Could you open an issue on the opentui repo so we can track it there?
Activity
[-]Support light mode[/-][+]Support dark/light mode os sync[/+]adamdotdevin commentedon Jun 27, 2025
it should already support this, can you share more about what you're seeing?
stordahl commentedon Jun 27, 2025
Just did some testing and it seems to be an issue in Wezterm where I only get dark mode for all themes
ChristianPavilonis commentedon Aug 26, 2025
Same using Zellij with kitty. (kitty outside of zellij works fine though)
treyhunner commentedon Sep 24, 2025
I believe I am experiencing this same issue.
Running opencode within tmux in Gnome Terminal always shows dark mode, even though my system is always configured for light mode.
stordahl commentedon Sep 24, 2025
@adamdotdevin I've recently moved to ghostty and, inside tmux, more of the UI seems to adapt when I change from dark mode to light mode, but the chat input and status bar don't update. Sometimes I even have to quit all opencode sessions, quit ghostty, and then the ui renders correctly
Artawower commentedon Oct 2, 2025
The same problem occurs with zellij + wezterm; the system theme does not change the input fields:
erf commentedon Nov 16, 2025
I'm using Ghostty on MacOS Thaoe and have it configured for both light and dark mode. If i change the OS theme from light to dark mode, the terminal will change theme as well. If i run
opencode, it will show the same mode - howeveropencodewon't detect OS theme changes when already running. Is it possible to listen for these changes?Note: i haven't configured theme for opencode but relying on the Ghostty configuration
rekram1-node commentedon Nov 16, 2025
I think @kommander would know best as to if it's possible and what may not be
kommander commentedon Nov 16, 2025
It is possible, with the caveat that not all terminals support it, but I'll support that event from opentui so opencode will be able to change the theme type automatically.
astrolox commentedon Nov 21, 2025
I've started using the new opentui version of this.
I'm finding that I have to manually switch it to light mode each time I open it.
I'm also using a terminal and custom color scheme which most software is unable to detect as being either light or dark.
I investigated how to fix this in the past and found a solution using an environment variable called COLORFGBG (it's supported by a bunch of terminals and software). So in software I've written in the past I've included a fallback to reading this variable if the normal detection doesn't work. Would you be willing to include that feature in opencode please?
If not; is there some way to change the default from dark to light?
rekram1-node commentedon Nov 25, 2025
@astrolox I fixed it so the light vs dark is persisted
astrolox commentedon Nov 25, 2025
Having it persisted is certainly an improvement. Thank you.
That said; sometimes I switch from light to dark depending on environment (day time office usage vs late night on call work). So improving the detection would be ideal as a future enhancement.
stordahl commentedon Nov 25, 2025
This is my workflow as well so +1 on this callout
pvinis commentedon Dec 5, 2025
ill also put a repro here.
i have iterm to swap colors on macos appearance change, so light mode has light grey background, and dark mode has black background.
so with that, when i have an iterm window open, and i toggle from light to dark mode, my iterm window changes its colors.
but if i do that while having opencode running, it never changes.
see here. claude, opencode and codex. claude is the only one handling things correctly.
dark mode
flip to light mode
smrdotgg commentedon Dec 20, 2025
I think I've found the root cause!
TL;DR: If OpenCode isn't detecting your OS theme changes in tmux, try detaching and re-attaching to your tmux session (then restarting OpenCode if its still open)
After investigation, I've deduced that tmux captures the system theme in some variable on attachment. This is why on my setup (Macbook, Ghostty, Oh-my-tmux, Neovim, Opencode), I have to detach and re-attach to tmux, then restart OpenCode for it to actually get the proper theme.
The reason Neovim automatically switches is because for most people (including me) neovim is set up to check the actual system settings to see if its on dark mode.
But for OpenCode (and even other CLI's like
git-delta), the theme data seems to rely on information that tmux captures and updates when the user creates a new session or attaches to an existing session.I believe that is the key issue. You guys can test this theory. I have tested it rigorously and it has checked out consistently for me.
Let me know if this helps!!
thdxr commentedon Mar 25, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.
astrolox commentedon Mar 25, 2026
Please consider supporting COLORFGBG before closing this issue 😉
kommander commentedon Mar 26, 2026
Interesting, I didn't know about that one. Could work at least for initial detection. Could you open an issue on the opentui repo so we can track it there?
fix(session): remove duplicate new messages indicator (anomalyco#480)