claude-code - 💡(How to fix) Fix TUI hangs forever on macOS Tahoe 26.5 Terminal.app — DA1 query response missing

Summary

Claude Code TUI (claude без --print flag) hangs indefinitely at initialization on macOS Tahoe 26.5 (build 25F71) when launched from system Terminal.app. The same binary works fine in iTerm2, VS Code integrated terminal, and --print non-interactive mode.

Root cause: Terminal.app v470.2 on macOS Tahoe 26.5 stopped responding to the Primary Device Attributes (DA1) query (ESC [ c / \033[c). Claude TUI sends DA1 at boot and waits forever for the response, which never arrives. This is a regression in Terminal.app (Apple bug, not Claude Code), but it silently breaks claude for users who can't easily switch terminal emulators.

Environment

• Claude Code: 2.1.148 and 2.1.149 (both affected)
• macOS: Tahoe 26.5 (build 25F71), Apple Silicon
• Terminal.app: v470.2 (system default)
• Shell: zsh 5.9
• TERM: xterm-256color

Reproduction

# In Terminal.app on macOS 26.5
printf '\033[c'; sleep 1 | od -c

Expected output (DA1 query + reply):

0000000  033   [   c 033   [   ?   1   ;   2   c
0000013

Actual output (only the printf bytes, no DA1 reply):

0000000  033   [   c
0000003

Same command in iTerm2 returns the expected reply within milliseconds.

Impact on Claude Code

1. Launch claude in Terminal.app → TUI never renders. Process stays alive forever waiting on DA1 reply.
2. Sample shows main-thread + Bun Pool workers all idle in __workq_kernreturn (kqueue wait).
3. claude does successfully establish HTTPS connections to Anthropic Cloud (verified via lsof -a -p <PID> -i), so authentication/network is OK — only the TUI render loop is blocked.
4. New session jsonl file is not created in ~/.claude/projects/<workspace>/ — claude never advances past terminal capability negotiation.

Workarounds tested (none fully successful in Terminal.app)

• TERM=dumb, TERM=vt100, TERM=ansi, TERM=xterm-mono, TERM=screen, TERM=screen-256color — all hang the same way
• Downgrade claude binary to 2.1.146/147/148 — same hang
• --bare flag (no hooks/MCP/plugins) — same hang
• --exclude-dynamic-system-prompt-sections — same hang
• expect wrapper injecting ^[[?1;2c DA1 reply — claude passes DA1 stage but TUI still doesn't render (suggests Tahoe Terminal.app may be broken on additional capability queries besides DA1)
• claude --print mode — works correctly (proves binary OK, isolates bug to interactive TUI codepath)

Working alternatives

• iTerm2 (v3.6.10) — TUI works correctly
• VS Code integrated terminal (xterm.js) — TUI works correctly
• Sessions already running on macOS before the bug appeared — still functional (they cached DA1 capability response in memory and never re-query)

Suggestion / Feature request

Could Claude Code:

1. Add a DA1 query timeout (e.g., 500ms) with fallback to default capability set if no reply arrives? This would prevent infinite hang and allow TUI to launch with degraded but functional capabilities.

2. Provide an env var (e.g., CLAUDE_CODE_SKIP_TERMCAP=1) that bypasses DA1 negotiation entirely for users stuck on broken terminals?

3. Detect Terminal.app on macOS 26.5 and emit a warning + auto-fallback?

This would help users on macOS Tahoe who can't easily switch terminal emulators (corporate restrictions, workflow dependencies, etc.). Currently, the hang is silent — claude binary stays alive with no error message, so users may not realize Terminal.app is the culprit and may blame Claude Code instead.

Reference

• Local incident wiki documentation: full diagnostic + multi-AI consilium (DeepSeek-R1 + Gemini 2.5 Pro + GPT-4o) all converged on Terminal.app DA1 bug as root cause.
• Apple Feedback Assistant: blocked from submission without Beta Software Program enrollment, hence GitHub issue here for now.

Related questions

• Are other Claude Code users on macOS 26.5 seeing this?
• Anthropic team — do you have a contact at Apple Mac engineering who could escalate Terminal.app DA1 regression?
• Is there an internal workaround being considered (e.g., DA1 timeout in upcoming Claude Code release)?