Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] TUI input completely unresponsive starting in 2.1.113 (Linux kernel 3.10) [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#50819•Fetched 2026-04-20 12:12:11
View on GitHub
Comments
2
Participants
2
Timeline
8
Reactions
0
Author
foobargeezfoobargeez
Participants
foobargeezfoobargeezgithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×6commented ×2

Error Message

Error Messages/Logs

Root Cause

  • TUI banner/layout renders correctly
  • Escape sequences leak into input box ([>0q, [<u]9;4;0; visible as literal text)
  • No keystrokes reach the TUI (tested: letters, arrows, Enter)
  • Session exits cleanly at 30s with "No API key available" because auth dialog input is also dead
  • Shell raw-mode input works fine outside Claude Code (read -n 1, cat, less all responsive)
  • claude --print "..." works perfectly
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

TUI renders but accepts no keyboard input (arrows, typing, Enter all ignored). --print mode works fine. Bisected to 2.1.113 — 2.1.112 works perfectly. Bisect:

  • 2.1.91 ✅ works
  • 2.1.110 ✅ works
  • 2.1.112 ✅ works
  • 2.1.113 ❌ broken
  • 2.1.114 ❌ broken

Environment:

  • Claude Code installed via npm global in a Debian 12 container
  • Container host: CentOS 7, kernel 3.10.0-1160.88.1.el7.x86_64
  • Container attached via docker exec -it over SSH from macOS
  • Node v23.11.1 in container
  • TERM=xterm-256color

Symptoms:

  • TUI banner/layout renders correctly
  • Escape sequences leak into input box ([>0q, [<u]9;4;0; visible as literal text)
  • No keystrokes reach the TUI (tested: letters, arrows, Enter)
  • Session exits cleanly at 30s with "No API key available" because auth dialog input is also dead
  • Shell raw-mode input works fine outside Claude Code (read -n 1, cat, less all responsive)
  • claude --print "..." works perfectly

Suspected cause: Likely a Bun runtime bump or TTY input path change in 2.1.113 that uses a syscall or epoll behavior unsupported by kernel 3.10's legacy epoll. Modern kernels likely unaffected.

What Should Happen?

TUI should be responsive

Error Messages/Logs

Steps to Reproduce

Just installing 2.1.113 in the provided environment reproduces the issue i.e., TUI goes unresponsive.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.112

Claude Code Version

2.1.112

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

extent analysis

TL;DR

Downgrade to version 2.1.112 or wait for a fix that addresses the suspected incompatibility with kernel 3.10's legacy epoll.

Guidance

  • Verify that the issue is indeed caused by the Bun runtime bump or TTY input path change in 2.1.113 by checking the release notes or changelog for that version.
  • Test the TUI with a modern kernel to confirm that the issue is specific to kernel 3.10.
  • Consider upgrading the kernel of the CentOS 7 host to a version that supports modern epoll behavior, if possible.
  • If downgrading to 2.1.112 is not feasible, explore alternative input methods or workarounds that do not rely on the TUI.

Notes

The issue seems to be specific to the combination of Claude Code 2.1.113, kernel 3.10, and the Debian 12 container environment. The fact that --print mode works fine and shell raw-mode input works outside Claude Code suggests that the issue is isolated to the TUI.

Recommendation

Apply workaround: Downgrade to version 2.1.112, as it is confirmed to work correctly in the provided environment.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#environment setup#docker error#permission error#memory optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING