Opencode freezes when pressing option + left arrow key on MacBook with high CPU usage #1764

Open
opened 2026-02-16 17:32:31 -05:00 by yindo · 6 comments
Owner

Originally created by @h4ni0 on GitHub (Sep 19, 2025).

Originally assigned to: @adamdotdevin on GitHub.

When I'm in opencode, and I press option + left arrow key, opencode freezes and I notice this process that spikes:

Image
Originally created by @h4ni0 on GitHub (Sep 19, 2025). Originally assigned to: @adamdotdevin on GitHub. When I'm in opencode, and I press `option` + left arrow key, opencode freezes and I notice this process that spikes: <img width="270" height="85" alt="Image" src="https://github.com/user-attachments/assets/a3c46413-7590-4039-9933-f9b69f0535fe" />
Author
Owner

@rekram1-node commented on GitHub (Sep 19, 2025):

That's weird I can replicate, this may be fixed once opentui migration is complete

@rekram1-node commented on GitHub (Sep 19, 2025): That's weird I can replicate, this may be fixed once [opentui migration](https://github.com/sst/opencode/pull/2685) is complete
Author
Owner

@aemr3 commented on GitHub (Sep 19, 2025):

When I'm in opencode, and I press option + left arrow key, opencode freezes and I notice this process that spikes:

yes I have experienced it as well, I'm using shift + arrow keys without any problems.

{
  "keybinds": {
    "session_child_cycle": "shift+right",
    "session_child_cycle_reverse": "shift+left"
  }
}
@aemr3 commented on GitHub (Sep 19, 2025): > When I'm in opencode, and I press `option` + left arrow key, opencode freezes and I notice this process that spikes: yes I have experienced it as well, I'm using shift + arrow keys without any problems. ``` { "keybinds": { "session_child_cycle": "shift+right", "session_child_cycle_reverse": "shift+left" } } ```
Author
Owner

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

Just ran into the same issue since v0.13.4 (see #2854) but also noticed that it only had this issue with Ghostty (1.2.0). Will close my other issue and follow this one for a solution 🤞

@lloydrichards commented on GitHub (Sep 29, 2025): Just ran into the same issue since v0.13.4 (see #2854) but also noticed that it only had this issue with Ghostty (1.2.0). Will close my other issue and follow this one for a solution 🤞
Author
Owner

@lloydrichards commented on GitHub (Oct 1, 2025):

in v0.13.7, I'm no longer having this issue

@lloydrichards commented on GitHub (Oct 1, 2025): in v0.13.7, I'm no longer having this issue
Author
Owner

@towry commented on GitHub (Oct 24, 2025):

Image

opencode: 0.15.15
ghostty: 9dc2e5978
macos: 26.0.1


I mapped the right command to ctrl, and press right command + arrow when input is empty, it will freeze tui. if there are characters like "sjdfj", press right command + arrow will move the cursor.

@towry commented on GitHub (Oct 24, 2025): <img width="723" height="118" alt="Image" src="https://github.com/user-attachments/assets/539aafd6-9140-41b8-bbd5-2d669c858705" /> opencode: 0.15.15 ghostty: 9dc2e5978 macos: 26.0.1 --- I mapped the right command to ctrl, and press right command + arrow when input is empty, it will freeze tui. if there are characters like "sjdfj", press right command + arrow will move the cursor.
Author
Owner

@pedropombeiro commented on GitHub (Feb 7, 2026):

I've traced the root cause of this issue to the @opentui/core package's stdin buffer handling.

Root Cause

In packages/core/src/lib/stdin-buffer.ts, the isCompleteSequence function doesn't handle double-escape sequences (like \x1b\x1b[D for Option+Left). When the terminal sends this sequence:

  1. The function sees it starts with ESC (\x1b)
  2. afterEsc = \x1b[D (starts with ESC, not [)
  3. None of the pattern checks match
  4. Falls through to return "complete" - treating \x1b\x1b as complete
  5. The remaining [D is emitted as literal text

This is why users see [D or [C printed instead of cursor movement.

Filed Upstream

I've filed an issue with a proposed fix in the opentui repo:
https://github.com/anomalyco/opentui/issues/644

@pedropombeiro commented on GitHub (Feb 7, 2026): I've traced the root cause of this issue to the `@opentui/core` package's stdin buffer handling. ## Root Cause In `packages/core/src/lib/stdin-buffer.ts`, the `isCompleteSequence` function doesn't handle double-escape sequences (like `\x1b\x1b[D` for Option+Left). When the terminal sends this sequence: 1. The function sees it starts with ESC (`\x1b`) 2. `afterEsc` = `\x1b[D` (starts with ESC, not `[`) 3. None of the pattern checks match 4. Falls through to `return "complete"` - treating `\x1b\x1b` as complete 5. The remaining `[D` is emitted as literal text This is why users see `[D` or `[C` printed instead of cursor movement. ## Filed Upstream I've filed an issue with a proposed fix in the opentui repo: **https://github.com/anomalyco/opentui/issues/644**
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1764