[BUG] claude-code 2.1.110 no longer sending DEC 2026 messages on terminals that support it

Status Fixed / completed
Reported on v2.1.110
Maintainer reply ✓ Yes — ashwin-ant
Activity 9 comments · opened Apr 16, 2026 · closed Apr 19, 2026
💡 Likely answer: A maintainer (ashwin-ant, collaborator) responded on this thread — see the highlighted reply below.

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?

Claude Code has supported the DEC 2026 synchronized output terminal extension for some time, which can help to reduce screen tearing and other artifacts when Claude redraws the scrollback buffer.

Since Claude 2.1.110, I've noticed Claude is no longer sending DEC 2026 enable/disable commands on my terminal which supports it. I use a modified version of the Emacs eat terminal emulator, which uses a TERM value of eat-truecolor. Its terminfo advertises the Sync capability, and it responds to DECRPM queries to test for the availability of the feature. I also tested setting my TERM value to xterm-256color to match iTerm, and Claude also does not send the sync messages.

Meanwhile, if I set my TERM to xterm-ghostty or xterm-kitty, Claude continues to send DEC 2026 instructions.

What Should Happen?

I assume Claude is now relying on a hardcoded list of terminal which support this feature, but this penalizes us users who run more obscure terminal emulators. Claude should support checking for DEC 2026 support using the DECRPM instruction, or a hardcoded list plus looking for the Sync feature in the terminfo (ghostty includes this feature in its custom terminfo, but other emulators such as iTerm that rely on a standard terminfo such as xterm-256color do not).

Error Messages/Logs

Steps to Reproduce

Launch claude in an affected terminal. When Claude produces a large amount of output, screen tearing will occur.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.109

Claude Code Version

2.1.112

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_

View original on GitHub ↗

8 Comments

github-actions[bot] · 4 months ago

Found 1 possible duplicate issue:

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

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

lucasec · 4 months ago

This issue is not related because it affects a much older version of Claude. Newer versions such as 2.1.109 did not have the issue.

lucasec · 4 months ago

Further testing reveals that Claude is filtering based on TERM_PROGRAM, not TERM. So while iTerm uses TERM=xterm-256color, which alone is not enough to enable synchronized output, Claude sees TERM_PROGRAM=iTerm.app and enables the feature.

Regardless, Claude should not be relying on a hardcoded list (except to override specific terminal emulator quirks), when a standard discovery mechanism exists.

ashwin-ant collaborator · 4 months ago

This has been fixed in a recent release — Restored DEC 2026 synchronized output for unlisted terminals by probing support via DECRQM at startup (fallback to the TERM_PROGRAM allowlist). If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

lucasec · 4 months ago

@ashwin-ant Thanks for the quick follow up. Is the fix supposed to be in 2.1.114? If so, I do not see any improvements yet. Keeping an eye on the release notes in case the release you referring to has not been published yet.

I added debug logging to my terminal emulator to confirm it does not appear to receive any DECRQM queries.

lucasec · 4 months ago

@ashwin-ant This issue is still not resolved as of 2.1.119. Can you re-open this issue for proper tracking?

lucasec · 4 months ago

Opened https://github.com/anthropics/claude-code/issues/55613 as this is still not resolved in 2.1.126. If Anthropic would like to re-open this issue and use it as the canonical tracker, feel free to close the new issue.

lucasec · 2 months ago

I meant to follow up on this sooner, but thanks for adding CLAUDE_CODE_FORCE_SYNC_OUTPUT (https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#21129). I was able to confirm this works.

It is still a little challenging for those of us developing terminal emulators that are not in the top 5-10 that get widely tested and hard-coded feature gating added. A rough list of functionality that a user on my patched branch of Eat would need to set up to get the full Claude Code experience:

  1. Set CLAUDE_CODE_FORCE_SYNC_OUTPUT to 1
  2. Set "Local Notifications" in Claude Code settings to OSC 777 or OSC 9
  3. It appears OSC 8 hyperlinks are also gated, though I discovered the gating can be escaped by setting FORCE_HYPERLINK (undocumented as far as I can tell)

From what I can tell, there is one feature that cannot be enabled at all outside of masquerading as an allow-listed terminal:

  1. Terminal progress bar support (OSC 9;4)

Overall, I know feature detection is a problem across the entire terminal application ecosystem. Best I can ask for is that the feature matrix gets documented somewhere and that everything limited to terminal name allowlist gets an escape hatch like was added here.

Showing cached comments. Read the full discussion on GitHub ↗