Editor in a new window, zoomed in, typing from right to left

Support Bug Reports
,
26

The issue persists even after setting this option to true. I’m on windows 10.

27

same issue still persists on windows 11

28

Hey @Jinyi, @z6m8n7ljw, thanks for getting back to us. This is a useful datapoint. It means the GPU acceleration workaround is a macOS-specific fix and it doesn’t cover Windows. It looks like the trigger on macOS is slightly different, or there’s an extra code path, and that gives the team a better signal on where to dig.

Honestly, for Windows and Linux in the detached-window scenario, there isn’t a stable workaround yet. window.zoomLevel only helps if the reason for using a separate window is font size, and it doesn’t work well for multi-monitor setups.

We’re tracking the bug, and the scope has been expanded to all three OSes. I can’t share an ETA yet, but I’ll post an update here as soon as I have one. If anyone finds a workaround on Windows or Linux, please share it and I’ll add it to the thread.

30

Hey, I want to share a workaround that came up in a thread from @bricks and was confirmed by a separate report. On macOS, it looks like it really helps.

Try turning off GPU acceleration:

  • Ctrl+Shift+P on macOS Cmd+Shift+P then Preferences: Configure Runtime Arguments
  • In the argv.json file that opens, add this line: "disable-hardware-acceleration": true
  • Fully restart Cursor.

After that, focus and the caret in the torn-off agent window should behave normally, without reversed typing. @GertRhinoAfrica, you’re on macOS, let us know if this fixes it in your dual monitor setup.

For Windows and Linux users, there isn’t a more reliable workaround for the tear-off window yet, except using window.zoomLevel instead of a separate window if you only need bigger text. But since the bug is confirmed on all three OSes, it’s still worth trying to disable GPU acceleration. Please reply if it works for you.

We know about the bug and it’s being tracked, but I can’t share an ETA for a fix yet. Thanks to @bricks for the GPU tip, I added it to our issue notes. If you find any other workarounds, drop them here and we’ll collect them in one place.

31

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Description:
When I detach the chat panel into a separate window in Cursor IDE, the text input behaves incorrectly.

Steps to Reproduce:

Open Cursor IDE
Open the Chat panel
Detach the chat panel into a separate window
Start typing in the chat input field

Expected Behavior:
Typed text should appear normally from left to right.

Actual Behavior:
The typed characters appear in reverse order while writing, making the input difficult to use.

Additional Notes:
This issue only occurs when the chat panel is detached into a separate window. The normal embedded chat panel works correctly.

Steps to Reproduce

Steps to Reproduce:

  1. Open Cursor IDE
  2. Click the Chat panel from the top-right corner
  3. Open an existing conversation or start a new one
  4. Drag the chat tab outside of Cursor IDE to detach it into a separate window
  5. Close the same chat panel from the main Cursor IDE window, leaving only the detached window open
  6. Try typing a message in the detached chat window

Result:
The typed text appears in reverse order while writing.

Screenshots / Screen Recordings

asdasdadasd.png
asdasdadasd.png752×852 5.77 KB

Operating System

Windows 10/11

Version Information

Version: 3.6.31 (user setup)
VS Code Extension API: 1.105.1
Commit:
81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z (2 days ago)
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue