[BUG] Keystrokes typed during startup are not captured

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/7485

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I'm affected as well, here is my setup:

OS: macOS
Terminal: iTerm2 v3.6.6
Shell: zsh 5.9 (configuration)

As for the root cause, Claude suggests it could be raw mode:

it would need to snapshot any buffered stdin bytes before entering raw mode and replay them into the input handler.

This comment was generated by Claude Code (claude-opus-4-6) after analyzing the minified source in the npm package.

Analysis: Early Input Capture Mechanism

Claude Code already implements a typeahead buffer for capturing keystrokes during startup. The relevant exported functions are:

• startCapturingEarlyInput — enters raw mode and begins buffering stdin
• stopCapturingEarlyInput — removes the listener and exits raw mode
• consumeEarlyInput — calls stop, returns the buffered string (trimmed), and clears the buffer
• hasEarlyInput / isCapturingEarlyInput — status checks

Deobfuscated startup flow

// 1. Very early in CLI startup:
let { startCapturingEarlyInput } = await import(/* early input module */);
startCapturingEarlyInput();
// ... async import and run main() ...

// 2. startCapturingEarlyInput sets up raw mode and buffers keystrokes:
function startCapturingEarlyInput() {
  if (!process.stdin.isTTY || capturing) return;
  capturing = true;
  buffer = "";
  process.stdin.setEncoding("utf8");
  process.stdin.setRawMode(true);
  process.stdin.ref();
  listener = () => {
    let data = process.stdin.read();
    while (data !== null) {
      if (typeof data === "string") processChar(data);
      data = process.stdin.read();
    }
  };
  process.stdin.on("readable", listener);
}

// 3. The input component initializes its state with the buffer:
const [value, setValue] = useState(() => consumeEarlyInput());

// 4. consumeEarlyInput stops capturing and returns the buffer:
function consumeEarlyInput() {
  stop();                    // removes listener, exits raw mode
  let result = buffer.trim();
  buffer = "";
  return result;
}

Likely causes of character loss

1. Async import gap before capture starts — there is an await import() that must resolve before startCapturingEarlyInput() is called. Characters typed during this window are lost because nothing is reading stdin yet and the terminal is still in cooked mode.

1. Handoff gap between early capture and ink's raw mode — consumeEarlyInput() calls stop(), which removes the stdin listener and calls setRawMode(false). Then ink independently calls setRawMode(true) and attaches its own listener. Characters typed in between are lost.

1. .trim() strips whitespace — consumeEarlyInput trims the buffer, so leading/trailing spaces are silently dropped.

1. Newlines are skipped in the character processing loop — if the user types characters and presses Enter before the TUI renders, the newline is discarded.

The handoff gap (point 2) is the most likely cause of the reported character loss, since it's a race condition that would manifest inconsistently depending on startup timing.

Affecting me and a few others I work with as well, another data point: https://github.com/anthropics/claude-code/issues/28080

Make sure to 👍 the issue for visibility.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Still an issue in v2.1.83.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.