anomalyco / anomalyco/opencode

Lowercase `l` requires double press only when TUI content grows (still reproducible on 1.18.22, terminal-independent)

Open
#44,781 1 comment 0 reactions 1 assignee View on GitHub

@kommander is already working on this.

Since Aug 24, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Description

Follow-up to #31568 (closed as not planned). This is not a duplicate: it confirms the regression still exists on 1.18.22 and adds a new repro variable — TUI content size — that was missing from the original report.

Symptom
  • Only lowercase l requires a double press; uppercase L works normally; all other keys register on first press.
  • Fresh/small session: single-press l works reliably right after launch.
  • Grown session: once model responses render and the message list expands the viewport, l starts requiring a double press.
  • The trigger tracks rendered content volume rather than session age; a fresh session always starts clean.
Environment
Item Value
opencode 1.18.22
OS Linux Mint 22.3 (X11)
Terminals tested Ghostty (GTK4), gnome-terminal
Keyboard layout tr + us
Plugins superpowers, opencode-models-discovery
Isolation tests
Test Result
ibus exit, then retry No change → not IME/XIM related
Reproduce in gnome-terminal instead of Ghostty Still reproduces → terminal-independent
Rapid l typing in plain bash in both terminals Zero dropped keys → shell/readline layer clean
Rebind session_list away from l (mine is already <leader>s) No effect → consumer is not that binding
Hypothesis

The first l keypress appears to be consumed by a race between key event processing and rendering once the render/diff cost grows with content size. Consistent with the leader-chord suspicion in #31568, but the size-dependence points at a timing/render interaction rather than a static binding.

Happy to test patches or capture debug output if there's a flag for raw key events

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.