[BUG] TUI rendering corrupted in neovim's built-in terminal (macOS)

Screenshot

<img width="604" height="152" alt="Image" src="https://github.com/user-attachments/assets/4518234e-b983-4621-9df3-010609322444" />

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/19533
2. https://github.com/anthropics/claude-code/issues/17775
3. https://github.com/anthropics/claude-code/issues/14613

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

This is not a duplicate issue. It's possible that this has the same root cause as #19533, but this issue tracks a different platform

Workaround

Running Claude Code inside tmux within neovim's terminal resolves the rendering issues. tmux properly supports synchronized output (mode 2026) and translates the escape sequences correctly.

Setup

Add to your neovim config (~/.config/nvim/init.lua):

-- Open terminal with tmux (reattach to existing session or create new)
vim.api.nvim_create_user_command('T', function()
  vim.cmd('terminal tmux new-session -A -s main')
end, {})

Then use :T instead of :terminal, and run claude inside the tmux session.

---

Note: This is a workaround, not a fix. The underlying issue (Claude Code not gracefully degrading when mode 2026 is unavailable) still exists and affects users who don't want to use tmux.

I'm seeing this on macos in plain vim9 (which also uses libvterm).

@mgleonard425 has the 2026 mode support in neovim fixed this for you? Running nightly still seems to be causing tearing from time to time, could be that claude is doing very frequent batches

@Hoffs patially, not entirely. I think my PR in neovim fixed the worst of the garbling and random ASCII. However, the behavior exhibited in the screenshot I shared earlier still persists. I'm debugging this in my spare time - will update here if I manage to root-cause

Hi! I'm seeing similar garbled text as I edit in ghostty, iterm and terminal (all with and without using tmux).

• v2.1.85, macOS Darwin 25.4.0
• Affects Ghostty, iTerm, terminal, and tmux (so it's not mode 2026 passthrough)
• DA1/DCS responses (^[P>|tmux 3.6a^[\^[[?1;2;4c) leak into input on startup
• Backspace produces ?????, raw escape sequences ([[O, [[127;3u7;3uu, ^[[I) render as text
• Resizing the window triggers a clean re-render and fixes it temporarily

Some random diagnostic checks:

~/sandbox (next-master) % locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=
~/sandbox (next-master) %   echo $LANG $LC_ALL
en_US.UTF-8
~/sandbox (next-master) % echo $ZSH_THEME

~/sandbox next-master) % ich starship 2>/dev/null && echo "starship active"
~/sandbox next-master) % echo $GHOSTTY_SHELL_INTEGRATION_NO_CURSOR

~/sandbox (next-master) % node --version
v25.2.1 (also happens with node 22 for me)

~/sandbox (next-master) % sw_vers
ProductName:            macOS
ProductVersion:         26.4
BuildVersion:           25E246

<img width="1562" height="158" alt="Image" src="https://github.com/user-attachments/assets/117272fb-e9f3-4d58-bc60-b5a028d6aba0" />

Replying here in case it helps anyone. I discovered there was another python process that was also attached to stdin which was interfering with Claude Code from getting clean input.

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

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.