Description

When using Option+Arrow keys on macOS terminals (iTerm2, etc.), the double-escape sequence \x1b\x1b[D (Option+Left) is incorrectly split by the stdin buffer, causing [D to be printed as literal text instead of being recognized as a key event.

Environment

• Terminal: iTerm2 (with "Left Option key" set to "Esc+")
• OS: macOS
• Terminal sends: \x1b\x1b[D for Option+Left (verified with cat -v showing ^[^[[D)

Root Cause

In packages/core/src/lib/stdin-buffer.ts, the isCompleteSequence function doesn't handle the case where afterEsc starts with another ESC character (the double-escape pattern for meta/option modified keys).

Current flow for input \x1b\x1b[D:

1. Function sees sequence starts with ESC (\x1b)
2. afterEsc = \x1b[D
3. Checks: afterEsc.startsWith("[") → false (it starts with \x1b)
4. Checks: afterEsc.startsWith("]") → false
5. Checks: afterEsc.startsWith("O") → false
6. Checks: afterEsc.length === 1 → false (length is 3)
7. Falls through to return "complete" on line 74

This causes extractCompleteSequences to emit:

• \x1b\x1b as one "complete" sequence
• [D as literal text (the bug!)

Expected Behavior

The sequence \x1b\x1b[D should be kept together and recognized as Option/Meta + Left Arrow, as the parser in parse.keypress.ts already has logic to handle this (lines 331-337).

Proposed Fix

Add handling in isCompleteSequence for when afterEsc starts with ESC:

// Double-escape sequences: ESC ESC [...] for meta/option modified keys
if (afterEsc.startsWith("\u001b")) {
  // Recursively check if the rest is a complete escape sequence
  const innerResult = isCompleteSequence(afterEsc)
  return innerResult
}

Related Issues

• Opencode freezes when pressing option + left arrow key on MacBook with high CPU usage opencode#2688 - "Opencode freezes when pressing option + left arrow key on MacBook"
• OpenCode desktop on macOS doesn't recognize for option keys opencode#10756 - "OpenCode desktop on macOS doesn't recognize option keys"