Cursor integrated terminal silently corrupts large pasted input — reproducible byte loss vs Windows Terminal

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Describe the Bug
Cursor’s integrated terminal silently corrupts large pasted input before it reaches Claude Code.
I reproduced this with the exact same ~164 KB clipboard payload in Windows Terminal and Cursor’s integrated terminal.
Windows Terminal: PASS

  • 40/40 sentinels
  • 40/40 end-of-block markers
  • 40/40 control phrases
  • no cuts or joined lines
    Cursor integrated terminal: FAIL
  • 38/40 sentinels
  • 38/40 end-of-block markers
  • 38/40 control phrases
  • 18 separate corruption regions
  • missing text in the middle of the paste
  • adjacent surviving text joined together
  • one U+FFFD replacement character, indicating a UTF-8 sequence was cut mid-byte
    Environment
  • Cursor 3.22.12
  • Windows 11
  • WSL2
  • Claude Code 2.1.285
  • bundled node-pty: 1.1.0-beta42
    Steps to Reproduce
  1. Open Claude Code inside Cursor’s integrated terminal.
  2. Paste the attached ~164 KB test payload.
  3. Ask Claude to validate the 40 distributed sentinels and control markers.
  4. Observe missing sections and joined text.
  5. Repeat the exact same clipboard paste in Windows Terminal: all 40/40 markers arrive intact.
    Expected Behavior
    The complete clipboard contents should reach the terminal process without dropped or corrupted bytes.
    Actual Behavior
    Cursor silently drops bytes at multiple points inside the pasted text. There is no warning to the user.
    This is particularly dangerous with AI coding tools because the model receives an incomplete specification and continues executing as if the prompt were complete.
    I can provide the exact reproduction payload, paste-cache samples, screenshots and additional diagnostics.
    This appears consistent with the previously reported node-pty large-paste/non-blocking PTY write issue.

Steps to Reproduce

  1. Open Cursor 3.22.12 on Windows 11 with WSL2.
  2. Open Claude Code 2.1.285 inside Cursor’s integrated terminal.
  3. Copy the attached/reproduction payload (~164 KB) containing:
    • 40 distributed sentinel markers
    • 40 end-of-block markers
    • 40 control phrases
  4. Paste the entire payload into Claude Code in one operation.
  5. Ask Claude Code to verify all markers and visually inspect the received text for cuts or joined lines.

Result in Cursor integrated terminal:

  • 38/40 sentinels
  • 38/40 end-of-block markers
  • 38/40 control phrases
  • 18 separate corruption regions
  • missing bytes in the middle of the paste
  • surviving text joined together
  • one U+FFFD replacement character caused by a UTF-8 sequence being cut mid-character
  1. Repeat the exact same clipboard payload in Windows Terminal, using the same WSL environment and Claude Code version.

Result in Windows Terminal:

  • 40/40 sentinels
  • 40/40 end-of-block markers
  • 40/40 control phrases
  • no visible corruption

The issue is reproducible specifically through Cursor’s integrated terminal path.

Expected Behavior

The complete clipboard contents should be delivered byte-for-byte to the terminal process without truncation, dropped bytes, corrupted UTF-8 sequences, or joined text boundaries.

Large pastes should behave the same way in Cursor’s integrated terminal as they do in Windows Terminal.

If the terminal cannot accept the entire paste safely, it should fail explicitly rather than silently corrupting the input.

Operating System

Windows 10/11

Version Information

Version: 3.22.12 (user setup)
VS Code Extension API: 1.128.0
Commit: 3a92974361033b2051526321308c2740fe5912c0
Date: 2026-09-26T04:55:12.125Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

N/A — this is an integrated terminal / PTY input corruption issue, not a Cursor AI model issue.

The receiving application during reproduction was Claude Code 2.1.285. The corruption occurs before Claude Code processes the input and is reproducible by comparing Cursor’s integrated terminal against Windows Terminal.

Additional Information

Cursor 3.22.12 appears to bundle node-pty 1.1.0-beta42.

The observed behavior appears consistent with the known node-pty large-write / non-blocking PTY data-loss issue.

A previous real-world reproduction also showed:

Windows Terminal paste:
19,257 bytes / 921 lines

Cursor integrated terminal paste:
18,943 bytes / 902 lines

314 bytes were silently lost from the middle of the input. An entire section disappeared and the surviving text on both sides was joined together.

The larger controlled reproduction (~164 KB) produced 18 separate corruption regions throughout the input, including one U+FFFD replacement character consistent with a multibyte UTF-8 character being cut mid-sequence.

Related reports:

  • Cursor Forum: “Terminal paste truncation at ~1018 bytes — outdated node-pty (v1.1 vs v1.2)”
  • Cursor Forum: “Terminal freezes when pasting >1KB while Claude Code is running”
  • microsoft/node-pty PR #831

I can provide the exact ~164 KB reproduction payload and paste-cache samples if needed.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Lucas_Lopes, thanks for the detailed report and for the side-by-side comparison with Windows Terminal.

This is a known issue with how the integrated terminal handles very large pastes containing non-ASCII characters (accents, em dashes, emoji, etc.). The team is aware of it, and fixing it will require bumping the version of node-pty that Cursor uses, which is a bit of an effort and I have no ETA to share. That said, it’s on our radar!

In the meantime, the most reliable workaround is to save the prompt to a file in your workspace (for example prompt.md) and ask Claude Code to read that file instead of pasting it. Using Windows Terminal for large pastes also works, as you found.

One quick question so we can confirm the path: is the Cursor window connected to WSL (bottom-left corner shows “WSL: ”), or is it a local Windows window with a WSL terminal profile?

7

Yes — the Cursor window is connected directly to WSL.
The bottom-left corner shows WSL: Ubuntu 24.04.

The A/B test I reported was done with this same setup:

  • Cursor window connected directly to WSL
  • Claude Code running inside Cursor’s integrated terminal
  • The same clipboard payload pasted into Windows Terminal as the control

Windows Terminal received the payload intact, while Cursor’s integrated terminal showed distributed byte loss and text corruption.