Korean characters disappear in the input prompt when using WezTerm/Ghostty

[MunsuBahk]

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

1. Open WezTerm or Ghostty.
2. Run the opencode application.
3. Switch the input method to Korean.
4. Type any Korean word, for example, "안녕하세요".
5. 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).

6. Additional Context (추가 정보)

• A screen recording of the issue is attached. (문제를 녹화한 영상을 첨부합니다.)

2025-08-17.4.42.05.mov

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Syntax highlighting breaks for non-English text with file links, selection also behaves incorrectly #1857: Syntax highlighting breaks for non-English text with file links, selection also behaves incorrectly

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]

In packages/tui/internal/tui/tui.go, the width calculation function lipgloss.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]

Could you please help me test whether this PR has fixed the issue?

[iblea]

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]

It isn’t a perfect solution, but declaring TERM=screen allows opencode to display Korean correctly.

# Run like this
TERM=screen opencode

I haven’t checked with Ghostty or WezTerm, but I expect they’ll behave the same.

---

완벽한 해결법은 아닙니다만, TERM=screen를 선언하면 opencode가 정상적으로 한글을 출력합니다.

# 아래처럼 실행
TERM=screen opencode

ghosty와 wezterm 은 확인하지 못했지만, 아마 동일할 것으로 예상됩니다.

2025-09-29.9.20.05.mov

[zenyr]

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.

fastfetch

HOWEVER, even without tmux it works OKAY for me:

❯ echo $TERM
xterm-ghostty

---

Another cosmetic issue related to CJK (probably including emojis):

screenshot
This codepoint error seems like purely cosmetic. API request seems fine.