anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:30:30 -05:00 by yindo · 7 comments
yindo commented 2026-02-16 17:30:30 -05:00
Owner
Copy Link
Copy Source

Originally created by @MunsuBahk on GitHub (Aug 17, 2025).

Originally assigned to: @adamdotdevin on GitHub.

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).

  1. Additional Context (추가 정보)

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

https://github.com/user-attachments/assets/78c33414-eac6-4b61-ae47-54135d6cc3f4

Originally created by @MunsuBahk on GitHub (Aug 17, 2025). Originally assigned to: @adamdotdevin on GitHub. **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. (문제를 녹화한 영상을 첨부합니다.) https://github.com/user-attachments/assets/78c33414-eac6-4b61-ae47-54135d6cc3f4
yindo commented 2026-02-16 17:30:30 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Aug 17, 2025):

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

  • #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.

@github-actions[bot] commented on GitHub (Aug 17, 2025): This issue might be a duplicate of existing issues. Please check: - #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.
yindo commented 2026-02-16 17:30:30 -05:00
Author
Owner
Copy Link
Copy Source

@iblea commented on GitHub (Sep 21, 2025):

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.

https://github.com/charmbracelet/lipgloss/pull/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.

@iblea commented on GitHub (Sep 21, 2025): 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. <https://github.com/charmbracelet/lipgloss/pull/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.
yindo commented 2026-02-16 17:30:30 -05:00
Author
Owner
Copy Link
Copy Source

@XYenon commented on GitHub (Sep 22, 2025):

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

@XYenon commented on GitHub (Sep 22, 2025): Could you please help me test whether [this PR]() has fixed the issue?
yindo commented 2026-02-16 17:30:31 -05:00
Author
Owner
Copy Link
Copy Source

@iblea commented on GitHub (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.

Image
@iblea commented on GitHub (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. <img width="732" height="424" alt="Image" src="https://github.com/user-attachments/assets/e325b596-a865-4ff7-a34d-7e928ecdf988" />
yindo commented 2026-02-16 17:30:31 -05:00
Author
Owner
Copy Link
Copy Source

@egoavara commented on GitHub (Sep 28, 2025):

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 은 확인하지 못했지만, 아마 동일할 것으로 예상됩니다.

https://github.com/user-attachments/assets/d3282fa5-2679-4c0b-8e74-45bc07764dbc

@egoavara commented on GitHub (Sep 28, 2025): 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가 정상적으로 한글을 출력합니다. ```bash # 아래처럼 실행 TERM=screen opencode ``` ghosty와 wezterm 은 확인하지 못했지만, 아마 동일할 것으로 예상됩니다. https://github.com/user-attachments/assets/d3282fa5-2679-4c0b-8e74-45bc07764dbc
yindo commented 2026-02-16 17:30:31 -05:00
Author
Owner
Copy Link
Copy Source

@zenyr commented on GitHub (Sep 29, 2025):

I'm using opencode on tmux on ghostty on osx. It had been working okay-ish for me:

https://github.com/user-attachments/assets/7151d65a-b9eb-47b6-906f-7345732c4753

Note that there are indeed some disappearing Korean letters directly following NL but it's mostly cosmetic one.

fastfetch
Image

HOWEVER, even without tmux it works OKAY for me:

❯ echo $TERM
xterm-ghostty
Image

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

screenshot
Image
This codepoint error seems like purely cosmetic. API request seems fine.
@zenyr commented on GitHub (Sep 29, 2025): I'm using opencode on tmux on ghostty on osx. It had been working okay-ish for me: https://github.com/user-attachments/assets/7151d65a-b9eb-47b6-906f-7345732c4753 Note that there are indeed some disappearing Korean letters directly following NL but it's mostly cosmetic one. | fastfetch | |:---:| | <img width="523" height="647" alt="Image" src="https://github.com/user-attachments/assets/6d6fbcba-1b29-4a9e-95b4-5a98bf210668" /> | HOWEVER, even without tmux it works OKAY for me: ``` ❯ echo $TERM xterm-ghostty ``` <img width="957" height="465" alt="Image" src="https://github.com/user-attachments/assets/cfcac58f-d492-44e1-9194-cb3833881df3" /> ----- Another cosmetic issue related to CJK (probably including emojis): | screenshot | |:----| | <img width="570" height="911" alt="Image" src="https://github.com/user-attachments/assets/4e4e2dc2-efb8-4a23-ac6d-a69777305e42" /> | | This codepoint error seems like purely cosmetic. API request seems fine. |
yindo commented 2026-02-16 17:30:31 -05:00
Author
Owner
Copy Link
Copy Source

@kolkov commented on GitHub (Oct 20, 2025):

@iblea https://github.com/phoenix-tui/phoenix/discussions/3 - try to use our modern TUI Golang framework.

@kolkov commented on GitHub (Oct 20, 2025): @iblea https://github.com/phoenix-tui/phoenix/discussions/3 - try to use our modern TUI Golang framework.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1342
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?