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
Can we remove the windows label or add mac os too? For me it is 5s for input box to load and logs don't help much. It was waaay quicker one or two weeks ago.
This isn't just windows, it's like that on macos also. Using ghostty takes almost 10 seconds to load. Wezterm is much faster but still noticeably slower since their last big update.
This isn't just windows, it's like that on macos also. Using ghostty takes almost 10 seconds to load. Wezterm is much faster but still noticeably slower since their last big update.
@hijoe@mfattakhov@scratchmex Are you using the opencode system theme? I switched away from the system theme and the sluggishness went away immediately. The mismatch is likely in functions like getTerminalBackgroundColor:app.tsx:44-102
It can't all be here, as the timeout here is only 1 second, but I think there is a mismatch between the escape sequences that ghostty sends and what we are expecting. Let me know if switching themes resolves your issues as well.
I can confirm switching away from the system theme cuts the loading time in a bit more than half. Insane. The time from clear screen to the TUI render now is faster. Still slow overall
stty -echo -icanon min 0 time 5
printf'\033]10;?\007\033]11;?\007\033]12;?\007\033]13;?\007\033]14;?\007\033]15;?\007\033]16;?\007\033]17;?\007\033]19;?\007'
dd bs=1 count=512 2>/dev/null | /bin/cat -v stty sane
The root issue is in the interaction between the getPallette function in opentui and ghostty. Here are the different responses to this command in ghostty and wezterm:
We see that ghostty gets back 10, 11, 12 (foreground, background, cursor), but does not return the 17/19. However neither of them return 13, 14, 15, 16, all of which are expected from special colors to return cleanly:
This should lead to both wezterm and ghostty hanging, but there is a backup idleTimer that times out after 150ms of inactivity (no escape sequences). Ghostty has a really chatty protocol, although I haven't looked too closely into why:
It sends a continuous stream of these escape sequences, preventing the inactivity timeout from triggering.
The fix is in opetui, changing the timeout logic to only reset if the results table has been updated in the allotted time. It does not reset on unrelated escape sequences.
Reacted by Nick Breaton, Sleroq and Alfredo García
Activity
github-actions commentedon Jan 12, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
neriousy commentedon Feb 3, 2026
Fixed in #9675 - on windows the OmO postinstall was ran on each startup. In new release you should see a significant improvement
scarf005 commentedon Feb 6, 2026
on opencode 1.1.53 and oh-my-opencode 3.2.3, it still takes 3.5 seconds to load opencode in terminal
YanwuZeng commentedon Feb 11, 2026
Starting it takes 20s on my old desktop.
scratchmex commentedon Feb 17, 2026
this is how long it takes for me. opened inside an empty directory. this was not the case the first time I used it. it was way quicker
Screen.Recording.2026-02-17.at.12.20.28.p.m.mov
logs don't show anything
full log in DEBUG
mfattakhov commentedon Feb 18, 2026
Can we remove the windows label or add mac os too? For me it is 5s for input box to load and logs don't help much. It was waaay quicker one or two weeks ago.
Screen.Recording.2026-02-18.at.09.50.58.mov
log file:
hijoe commentedon Feb 18, 2026
This isn't just windows, it's like that on macos also. Using ghostty takes almost 10 seconds to load. Wezterm is much faster but still noticeably slower since their last big update.
scarf005 commentedon Feb 19, 2026
please also add linux label or remove windows label, while faster than 20s 3.5s still takes bit of time:
MaxDillon commentedon Mar 1, 2026
@hijoe @mfattakhov @scratchmex Are you using the opencode system theme? I switched away from the system theme and the sluggishness went away immediately. The mismatch is likely in functions like
getTerminalBackgroundColor:app.tsx:44-102It can't all be here, as the timeout here is only 1 second, but I think there is a mismatch between the escape sequences that ghostty sends and what we are expecting. Let me know if switching themes resolves your issues as well.
scratchmex commentedon Mar 1, 2026
I can confirm switching away from the system theme cuts the loading time in a bit more than half. Insane. The time from clear screen to the TUI render now is faster. Still slow overall
MaxDillon commentedon Mar 2, 2026
The root issue is in the interaction between the
getPallettefunction in opentui and ghostty. Here are the different responses to this command in ghostty and wezterm:ghostty:
wezterm:
We see that ghostty gets back 10, 11, 12 (foreground, background, cursor), but does not return the 17/19. However neither of them return 13, 14, 15, 16, all of which are expected from special colors to return cleanly:
This should lead to both wezterm and ghostty hanging, but there is a backup idleTimer that times out after 150ms of inactivity (no escape sequences). Ghostty has a really chatty protocol, although I haven't looked too closely into why:
It sends a continuous stream of these escape sequences, preventing the inactivity timeout from triggering.
The fix is in opetui, changing the timeout logic to only reset if the results table has been updated in the allotted time. It does not reset on unrelated escape sequences.
CypherpunkSamurai commentedon Mar 2, 2026
@MaxDillon are you just using the record feature in zeterm to dump the ansi? or is it just cat tty device dump
MaxDillon commentedon Mar 2, 2026
@CypherpunkSamurai I used the command listed at the top of my comment:
for asking for reported colors.
The
ESC [ Iescape sequences, however, turned out to be the real issue as discovered in my fix hereanomalyco/opentui#765
Those I got by logging the buffer data directly in the onBuffer function in opentui
mfattakhov commentedon Mar 2, 2026
wow, @MaxDillon thx! it really helped a lot, its still not instant but much more usable. thou I use web ui more and more these days
yassine-safraoui commentedon Jun 24, 2026
I'm running into this on Windows, startup time is 11 seconds. I'm on 1.17.9, using Windows Terminal app.