[BUG] TUI regression between 2.1.29 and 2.1.34 — interactive mode dies silently on Linux SSH/HPC

Preflight Checklist

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

What's Wrong?

[BUG] TUI regression between 2.1.29 and 2.1.34 — interactive mode dies silently on Linux SSH/HPC

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Interactive mode (TUI) dies silently after rendering on Linux clusters accessed via SSH. The TUI briefly appears then exits with no error message, no crash log, no output whatsoever. Non-interactive mode (claude -p) works perfectly.

This is a regression: version 2.1.29 works, versions 2.1.30+ do not.

Environment

• Platform: Linux (two independent NSF HPC clusters (ACCESS-CI), both Ubuntu-based)
• Access method: SSH to cluster → interactive compute node
• Terminal multiplexer: Tested with and without screen — same failure
• TERM: Tested screen.xterm-256color and xterm-256color — same failure
• Claude Code version: 2.1.34 (also tested 2.1.30–2.1.33, all fail)
• Installation method: Native installer via curl -fsSL https://claude.ai/install.sh | bash

Steps to Reproduce

1. SSH into a Linux cluster
2. Launch an interactive compute node
3. Run claude (interactive mode)
4. TUI renders briefly, then exits silently — no error, no output

What I've Tried

• Fresh install (nuked ~/.claude, ~/.claude.json, ~/.config/claude, ~/.cache/claude, binary)
• export TERM=xterm-256color
• stty rows 50 cols 145
• script -q /dev/null -c "claude" (workaround from #12507 — did NOT help)
• SHELL=/bin/sh claude
• Two completely independent clusters — identical failure

Debug Log Analysis

2.1.34 debug log shows:

• [render] initLayout complete ✓
• [REPL:mount] REPL mounted ✓
• [render] first ink render ✓
• High write ratio: blit=0, write=1194 (100.0% writes), screen=20x145 ← zero successful blits
• Then silence — no error, no crash

2.1.34 with xterm-256color:

• Same render sequence completes
• Filesystem operations take seconds (likely blocking on network calls, not disk)
• Lock acquisition took longer than expected - another Claude instance may be running
• Then silence

Key Observations

• -p (non-interactive) mode works fine on 2.1.34 — backend/auth/API is not the issue
• 2.1.29 TUI works perfectly, including with --model claude-opus-4-6
• Two independent clusters broke on the same day, ruling out local infrastructure
• The script PTY wrapper that fixes #12507 does NOT fix this
• Zero blits in debug log suggests the TUI rendering pipeline changed between 2.1.29 and 2.1.30

Impact

• Blocks interactive Claude Code usage on Linux HPC clusters
• Workaround (pinning 2.1.29 + CLAUDE_AUTO_UPDATE=0) works but is fragile
• Max subscribers cannot use Opus 4.6 interactively on clusters if the new binary is required

Related Issues

• #12507 (similar symptoms on HPC but different root cause — script workaround doesn't apply here)
• #11898 (TUI suspend/raw mode issues)

What Should Happen?

Claude code should not silently fail with no error messages or logs after version 2.1.29

Error Messages/Logs

Steps to Reproduce

Simply run claude on a linux HPC!

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.29

Claude Code Version

2.1.34 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

_No response_