Repository navigation
Korean characters disappear in the input prompt when using WezTerm/Ghostty #2013
Description
1. Bug Description : When I type Korean (Hangul) characters in the opencode input prompt using terminals like
WezTerm or Ghostty, the completed characters are displayed for a moment and then disappear. This issue does not occur in the
default macOS Terminal.app. It seems to be a rendering or character width calculation issue with full-width characters.
2. Environment
• opencode Version: 0.5.5
• Operating System: macOS Sequoia 15.6
• Terminal Emulator: wezterm 20240203-110809-5046fc22 / Ghostty 1.1.3
• Shell: Zsh 5.9
• LANG Environment Variable: ko_KR.UTF-8
3. Steps to Reproduce
- Open WezTerm or Ghostty.
- Run the opencode application.
- Switch the input method to Korean.
- Type any Korean word, for example, "안녕하세요".
- Press space or enter.
4. Expected Behavior : The text "안녕하세요" should remain visible in the input prompt.
5. Actual Behavior (실제 결과) The text "안녕하세요" appears correctly as it's being typed, but disappears immediately after
the composition is finished (e.g., after pressing space).
- Additional Context (추가 정보)
• A screen recording of the issue is attached. (문제를 녹화한 영상을 첨부합니다.)
Activity
github-actions commentedon Aug 17, 2025
This issue might be a duplicate of existing issues. Please check:
While #1857 focuses on syntax highlighting and text selection issues with non-English text (Russian), it also mentions rendering problems with non-English characters in terminal emulators like Ghostty. Both issues involve character width calculation or rendering problems with full-width/non-English characters in terminal environments.
Feel free to ignore if this doesn't address your specific Korean input disappearing case.
iblea commentedon Sep 22, 2025
In
packages/tui/internal/tui/tui.go, the width calculation functionlipgloss.Width()is being used. As a result of arbitrarily modifying this, it was confirmed that Korean characters are broken and not displayed.charmbracelet/lipgloss#563
There is currently a Pull Request for the library in question that has modified the width calculation logic that is causing the problem.
When this Pull Request is reflected, it is expected that the bug can be fixed by updating the version of the library.
Thank you.
XYenon commentedon Sep 22, 2025
Could you please help me test whether this PR has fixed the issue?
iblea commentedon Sep 22, 2025
I tested it and found that while the pull request modifications have reduced Korean text corruption compared to before, Korean characters are still occasionally breaking, and cursor positioning is also problematic.
Looking briefly at the code, it appears that the width calculation functions are not currently unified.
Also, that PR seems to need additional verification. I'll comment on the related issues in that PR.
egoavara commentedon Sep 29, 2025
It isn’t a perfect solution, but declaring
TERM=screenallows opencode to display Korean correctly.I haven’t checked with Ghostty or WezTerm, but I expect they’ll behave the same.
완벽한 해결법은 아닙니다만,
TERM=screen를 선언하면 opencode가 정상적으로 한글을 출력합니다.# 아래처럼 실행 TERM=screen opencodeghosty와 wezterm 은 확인하지 못했지만, 아마 동일할 것으로 예상됩니다.
2025-09-29.9.20.05.mov
zenyr commentedon Sep 29, 2025
I'm using opencode on tmux on ghostty on osx. It had been working okay-ish for me:
opencode-on-tmux-on-ghostty_final_small.mp4
Note that there are indeed some disappearing Korean letters directly following NL but it's mostly cosmetic one.
HOWEVER, even without tmux it works OKAY for me:
Another cosmetic issue related to CJK (probably including emojis):
feat: improve Unicode width calculation for emoji and CJK (v2)
kolkov commentedon Oct 20, 2025
@iblea phoenix-tui/phoenix#3 - try to use our modern TUI Golang framework.
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.