Window dragging (via Title Bar) fails over Chrome Remote Desktop after updating to macOS 27 Golden Gate Beta

Hi everyone,

I recently updated my Mac to macOS 27 Golden Gate Beta and have encountered a strange issue with window management over a remote connection.

Issue: When connected to my Mac via Chrome Remote Desktop (CRD), I can no longer move application windows by dragging their title bars (outer frames).

Details:

Curiously, I can still drag and move individual tabs within apps (like Chrome or Terminal), which means mouse drag input itself is being transmitted correctly to the OS.

This issue only happens when attempting to drag the window title bar/frame over a remote session. Local mouse/trackpad control works perfectly.

Everything was working completely fine before the update to macOS 27 Golden Gate Beta.

What I've tried so far (with no success):

Toggled Accessibility permissions off and on for ChromeRemoteDesktopHost and restarted the Mac.

Disallowed and re-allowed Screen Recording permissions.

Completely re-installed the Chrome Remote Desktop host application.

Disabled "Tile windows by dragging to screen edges" in System Settings to avoid snapping conflicts.

It seems like WindowServer or the system-level window management is blocking or ignoring virtual mouse drag inputs specifically on title bars since this beta update.

Has anyone else experienced this on macOS 27 Golden Gate Beta, or is there a known API change / security restriction in this version that affects remote input handling for WindowServer?

Any insights or workarounds would be greatly appreciated.

Thank you!

Answered by DTS Engineer in 900688022

@sangraal

Thanks for the post, is the issue still happening with the latest beta?

macOS 27.0 beta 4. Released
 July 20, 2026 Build
26A5388g

As a temporary workaround, try using built-in Screen Sharing. You can enable this in System Settings > General > Sharing > Screen Sharing

Then you can use vnc://xxxx

Once you open the bug report, please post the FB number here for my reference. Reproduce the issue while running a sysdiagnose.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

Thanks

Albert  WWDR

Hi,

I have the same Problem with the Public Beta of Golden Gate

I also found no succes with CRD following the same steps to troubleshoot

My workaround: With DuetDisplay i can interact with the WindowServer as expected, but it is tedious especially on mobile

This is happening for me as well. The only solution I have found is resizing the window manually to ”move” it.

Accepted Answer

@sangraal

Thanks for the post, is the issue still happening with the latest beta?

macOS 27.0 beta 4. Released
 July 20, 2026 Build
26A5388g

As a temporary workaround, try using built-in Screen Sharing. You can enable this in System Settings > General > Sharing > Screen Sharing

Then you can use vnc://xxxx

Once you open the bug report, please post the FB number here for my reference. Reproduce the issue while running a sysdiagnose.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

Thanks

Albert  WWDR

This issue does not seem to be fixed. I upgraded to macos 27 yesterday.

Accessing mac mini remotely using Chrome Remote Desktop. Before I could drag application windows using the mouse by click-and-hold the title bar and dragging the window on the desktop. This does not work any longer - the window does not move. I can select other windows using the mouse. I also can select text in an app by dragging the mouse. Moving the app window is the problem.

Then you can use vnc://xxxx

By the way, Chrome Remote Desktop does NOT use vnc.

(Another story is that remote access to the mac using RealVNC failed around verison 26 - "protocol error: key length too large" )

it is also happening with final release (not beta) :(

Exact same issue here, upgraded to macOS 27 last night, now the windows can't be dragged when connecting remotely. Everything else works fine.

*I'm using nuoRDS (https://www.nuords.com/) for remote access, updated to latest available version for macOS 27 (nuoRDS Server 11 for macOS 27 Golden Gate Version: 11.0.2231.0 (BETA))

@omgstop Thanks for your post, have you filed a bug yet for that issue on the final release?

Once you open the bug report, please post the FB number here for my reference.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

Albert  WWDR

I'm experiencing the same issue since updating to macOS 27: FB24890907

FB24888567

Hi, This is also happening on a Mac Studio with a full release version of OS 27.0 and I am using RealVNC. It appears that you can resize windows but not move them around. Also the problem happens in Apps (Photoshop) and Finder (showing my age!!)

Mac Mini m6 here. Still an issue on public release of Golden Gate.

looks like Privacy & Security > Accessibility was removed and might be what’s causing this. Hopefully Apple can push out an update

Same issue on Mac mini 2023. Upgraded to MacOS 27.0 yesterday and cannot move windows remotely anymore. Sent feedback to Apple to hopefully prioritize a fix for this as remote work is imperative to many of us these days.

I got my new Mac Mini M5 Pro and upgarded to MacOS 27.0. I hit the same issue. That is frustrating as I expect my mac mini is a headless setup.

Same issue here! Just upgraded to macOS 27, dragging with mouse dragging window not longer working (when using mac through chrome remote desktop connection)

Claude Code just solved it for me:

Workaround: windows can't be dragged by the title bar over Chrome Remote Desktop on macOS 27

Cause: The Chrome Remote Desktop host (version 156 and earlier) sends drag events whose mouse event number doesn't match the mouse-down that started the drag. macOS 27 ignores those drags, so title-bar moves fail while clicks, resizing and tab dragging still work. Google has fixed this in the host for version 157 (Chromium issue 564169077), but until that ships, the small helper below applies the same correction locally: it copies the mouse-down's event number onto the drag/up events that follow. Physical mouse input already matches and passes through untouched. It only sees mouse button events (no keyboard, no network, no logging of what you click). Check your host version in Finder at /Library/PrivilegedHelperTools/ChromeRemoteDesktopHost (Get Info); remove this helper once it's 157 or later.


Prompt (paste into an AI assistant with access to your Mac, or follow the steps yourself):

Set up a helper on my Mac (macOS 27) that fixes title-bar window dragging over Chrome Remote Desktop. Do exactly the following:

  1. Create the folder ~/crd-dragfix and save this file in it as crd-dragfix.swift, unchanged:
// crd-dragfix: local stopgap for Chromium issue 564169077.
// Copies the mouse-down's event number onto the drag and up events that follow,
// the same correction Google made in the Chrome Remote Desktop host for v157.
// Sees only mouse button events: no keyboard, no logging of clicks, no network.
import Foundation
import ApplicationServices
import CoreGraphics

let verbose = CommandLine.arguments.contains("--verbose")

func log(_ message: String) {
  let stamp = ISO8601DateFormatter().string(from: Date())
  FileHandle.standardError.write("\(stamp) crd-dragfix: \(message)\n".data(using: .utf8)!)
}

enum Phase { case down, drag, up }

func classify(_ type: CGEventType) -> (button: Int, phase: Phase)? {
  switch type {
  case .leftMouseDown:     return (0, .down)
  case .leftMouseDragged:  return (0, .drag)
  case .leftMouseUp:       return (0, .up)
  case .rightMouseDown:    return (1, .down)
  case .rightMouseDragged: return (1, .drag)
  case .rightMouseUp:      return (1, .up)
  case .otherMouseDown:    return (2, .down)
  case .otherMouseDragged: return (2, .drag)
  case .otherMouseUp:      return (2, .up)
  default:                 return nil
  }
}

var pressNumber: [Int64] = [0, 0, 0]
var pressed: [Bool] = [false, false, false]
var correctedTotal = 0
var tapPort: CFMachPort?

let callback: CGEventTapCallBack = { _, type, event, _ in
  if type == .tapDisabledByTimeout || type == .tapDisabledByUserInput {
    if let tapPort { CGEvent.tapEnable(tap: tapPort, enable: true) }
    log("the system paused the event tap; re-enabled it")
    return Unmanaged.passUnretained(event)
  }
  guard let kind = classify(type) else { return Unmanaged.passUnretained(event) }
  let button = kind.button
  let number = event.getIntegerValueField(.mouseEventNumber)

  switch kind.phase {
  case .down:
    pressNumber[button] = number
    pressed[button] = true
  case .drag, .up:
    if pressed[button] && number != pressNumber[button] {
      event.setIntegerValueField(.mouseEventNumber, value: pressNumber[button])
      correctedTotal += 1
      if correctedTotal == 1 {
        log("corrected the first mismatched drag event; the fix is working")
      }
      if verbose {
        log("event type \(type.rawValue): number \(number) -> \(pressNumber[button])")
      }
    }
    if kind.phase == .up { pressed[button] = false }
  }
  return Unmanaged.passUnretained(event)
}

var mask: CGEventMask = 0
let watched: [CGEventType] = [
  .leftMouseDown, .leftMouseDragged, .leftMouseUp,
  .rightMouseDown, .rightMouseDragged, .rightMouseUp,
  .otherMouseDown, .otherMouseDragged, .otherMouseUp,
]
for t in watched { mask |= CGEventMask(1) << CGEventMask(t.rawValue) }

if !AXIsProcessTrusted() {
  let options = [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String: true] as CFDictionary
  _ = AXIsProcessTrustedWithOptions(options)
  log("waiting for permission: System Settings > Privacy & Security > Accessibility > crd-dragfix")
  while !AXIsProcessTrusted() { sleep(2) }
  log("Accessibility permission granted")
}

guard let tap = CGEvent.tapCreate(tap: .cgSessionEventTap, place: .headInsertEventTap,
                                  options: .defaultTap, eventsOfInterest: mask,
                                  callback: callback, userInfo: nil) else {
  log("could not create the event tap even though Accessibility is granted")
  exit(1)
}
tapPort = tap
let source = CFMachPortCreateRunLoopSource(kCFAllocatorDefault, tap, 0)
CFRunLoopAddSource(CFRunLoopGetCurrent(), source, .commonModes)
CGEvent.tapEnable(tap: tap, enable: true)
log("active on \(ProcessInfo.processInfo.operatingSystemVersionString)")
CFRunLoopRun()
  1. In Terminal, build and sign it (if swiftc is missing, run xcode-select --install first):
cd ~/crd-dragfix
xcrun swiftc -O -swift-version 5 -o crd-dragfix crd-dragfix.swift \
  -framework ApplicationServices -framework CoreGraphics
codesign --force --sign - --identifier local.crd-dragfix crd-dragfix
  1. Make it run now and at every login:
mkdir -p ~/Library/LaunchAgents ~/Library/Logs
cat > ~/Library/LaunchAgents/local.crd-dragfix.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>local.crd-dragfix</string>
  <key>ProgramArguments</key><array><string>$HOME/crd-dragfix/crd-dragfix</string></array>
  <key>RunAtLoad</key><true/>
  <key>KeepAlive</key><true/>
  <key>ThrottleInterval</key><integer>10</integer>
  <key>ProcessType</key><string>Interactive</string>
  <key>StandardErrorPath</key><string>$HOME/Library/Logs/crd-dragfix.log</string>
</dict>
</plist>
EOF
launchctl bootout gui/$(id -u)/local.crd-dragfix 2>/dev/null
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/local.crd-dragfix.plist
  1. When macOS asks, allow crd-dragfix in System Settings > Privacy & Security > Accessibility. (If rebuilding later, remove the old crd-dragfix entry with the minus button first, then enable the new one.)

  2. Drag a window by its title bar over Chrome Remote Desktop. tail ~/Library/Logs/crd-dragfix.log should show "corrected the first mismatched drag event; the fix is working".

To remove it once the host is version 157 or later:

launchctl bootout gui/$(id -u)/local.crd-dragfix
rm ~/Library/LaunchAgents/local.crd-dragfix.plist
rm -r ~/crd-dragfix

Then remove crd-dragfix from the Accessibility list.

Hi everyone,

Thank you, @jll-info, for sharing the workaround and the information about the Chromium fix.

As the original poster, I wanted to add a quick update on the release timing:

  • The fix has been merged into Chromium and is planned for the Chrome Remote Desktop version 157 milestone.
  • On October 27, a Chrome Remote Desktop team member said that, if there are no problems, a new public version should be available within a week or two.
  • We’ll need to wait for the public release and verify that it resolves the issue.

You can follow the latest updates here:

https://issues.chromium.org/issues/564169077

Thank you to everyone who contributed to this thread, and to the Chromium team for working on the fix!