macOS 26.7 and 27: native Computer Use app.drag loses held button state; Finder drops and canvas drawing fail
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
Update: reproduced on both macOS 26.7 and macOS 27
The user supplied the following results from an assistant running on a second MacBook Air. These results were not directly executed by the assistant on the original machine. This report is no longer specific to macOS 27. The same Computer Use service and client versions fail on two macOS major versions and two desktop-app builds.
| Item | MacBook Air: second-machine report | Original Mac: locally verified |
|---|---|---|
| macOS | 26.7 (25G227) | 27.0 (26A5425a) |
| Desktop app | 26.901.41123 (7942) | 26.901.41600 (7982), after update/reinstall |
| Computer Use service | 26.831.1000926 (1000926) | 26.831.1000926 (1000926) |
| SkyComputerUseClient | 26.831.1000926 (1000926) | 26.831.1000926 (1000926) |
| unified-computer-use plugin | 26.901.41123 | Not separately verified |
| Finder file drop into folder | Failed twice; source still exists, destination does not contain it | Failed |
| Safari canvas stroke | Failed; zero drawn segments | Failed |
| Safari movement buttons | 0 | 0 |
The second-machine test explicitly used native app interfaces:
var finder = await cua.getApp('com.apple.finder');
await finder.drag([192,151], [287,170]);
var safari = await cua.getApp('com.apple.Safari');
await safari.drag([100,280], [650,440]);
Safari on that machine received:
pointerdown button=0 buttons=0
pointermove button=-1 buttons=0
pointerup button=0 buttons=0
No browser-specific drag API, AppleScript, or separate input generator was used. No system settings were changed in this follow-up. A manual physical-drag control has not yet been performed on the Air. The earlier apparent Air success was only a sidebar divider moving from x=158 to x=248; that is insufficient evidence of file drag-and-drop or a continuously held mouse button.
This shifts investigation toward the shared native component/injection path or another shared environmental factor. It does not yet establish the root cause or prove an update regression. The macOS-27-specific Deskflow comparison below should be treated only as background research, not an explanation for both machines.
What version of the Codex App are you using (From “About Codex” dialog)?
26.901.41600 (7982)
Bundled/native Computer Use: 26.831.1000926 (1000926).
What subscription do you have?
Not included in this report.
What platform is your computer?
macOS 27.0, build 26A5425a; Apple Silicon.
uname -mprs: Darwin 27.0.0 arm64 arm
Chrome 152.0.7977.76.
What issue are you seeing?
Native Mac Computer Use can click and move, but cua.getApp(...).drag(...) does not maintain the primary-button state as observed by the target app. Apple Notes drawing and Finder file dragging fail. In a local Chrome diagnostic page, down events have buttons=1, but movement during the native drag has buttons=0.
This is the native Mac app API, not the in-app browser/CDP API. The call completes without a tool error.
What steps can reproduce the bug?
- Open a local HTML page containing a large canvas and pointer/mouse event logging in Chrome. Choose two points inside the canvas from the app screenshot.
- Through the native Computer Use tool, run:
const app = await cua.getApp('com.google.Chrome');
await app.drag([400, 400], [800, 500]);
await app.getAXState();
- Observe that movement does not carry the held primary button. Representative captured output (coordinates relative to the test area):
pointerdown x=419 y=101 buttons=1 button=0 trusted=true
mousedown x=419 y=105 buttons=1 button=0 trusted=true
pointermove x=862 y=216 buttons=0 button=-1 trusted=true
pointerup x=862 y=216 buttons=0 button=0 trusted=true
mouseup x=862 y=216 buttons=0 button=0 trusted=true
click x=862 y=216 buttons=0 button=0 trusted=true
Minimal event-logging HTML for reproducing the button-state symptom:
<!doctype html>
<style>#pad { height:320px; background:#edf5ff; touch-action:none; user-select:none }</style>
<div id="pad">Drag inside this area</div><pre id="log"></pre>
<script>
const pad = document.querySelector('#pad');
const log = document.querySelector('#log');
for (const type of ['pointerdown','pointermove','pointerup','mousedown','mouseup','click']) {
pad.addEventListener(type, e => {
log.textContent += `${e.type} buttons=${e.buttons} button=${e.button} trusted=${e.isTrusted}
`;
});
}
</script>
Serve locally, open in Chrome, and adapt the two drag points to the actual screenshot. The HTML above is a reduced logger; the actual test page additionally draws canvas strokes only when movement has a nonzero buttons value.
What is the expected behavior?
Movement while dragging should retain buttons & 1, producing continuous strokes and allowing native file dragging. Manual trackpad dragging works: on the same Safari diagnostic page it produced visible strokes and many pointermove buttons=1 events. Native automated dragging also fails in Safari, although Safari reported buttons=0 even on down, so the Chrome result above is the clearer reproduction.
Additional information
Reproduced after:
- Updating/reinstalling the desktop app.
- Backing up the entire local Computer Use directory and installing a fresh official component from the reinstalled app bundle. Code-signature verification passed; process inspection confirmed the service ran from the new installation.
- Restarting the native service and resetting the CUA session.
- Pausing Computer History, then restarting with History stopped.
- Stopping all UU Remote processes, including its launch agent/daemon.
- Quitting Mos and MouseBoost Pro. A fresh
CGGetEventTapListinspection confirmed their taps disappeared. The remaining third-party tap was Raycast's keyboard-only mask (1024); the drag failure persisted. This checks event-tap interference, not every possible kind of software conflict. - Checking the relevant control/screen permissions and testing with full filesystem access.
A read-only target-process mouse-event tap observed the native service actually sending leftMouseDragged events; it is not simply omitting the drag event type. One sequence was:
mouseMoved eventNumber=12
leftMouseDown eventNumber=13 clickState=1
leftMouseDragged eventNumber=14 clickState=0 (three events)
leftMouseUp eventNumber=13 clickState=1
Temporary, target/source-restricted experiments aligning existing event numbers and drag clickState/pressure did not fix it. Those taps have been stopped. No official binary was patched or re-signed, and the final reproduction uses a fresh signed component without those taps.
An independent Swift CGEvent/HID drag helper did successfully drag a test file and draw in Notes on this same machine. This is only a diagnostic control, not a repair of app.drag().
Correction: the earlier report of working native dragging on the macOS 26 MacBook Air was based on moving a sidebar divider, not file drag-and-drop or sustained canvas drawing. Follow-up tests on that machine now reproduce this failure; see the cross-system comparison at the top. The Windows sky.drag success remains a user-provided result on a different backend.
Potentially related but different reports:
- #39116: Computer History interrupts manual Logic Pro dragging; stopping History did not resolve this case.
- #41356: macOS 27 helper crashes on click; our native drag returns successfully and clicking works.
- #38300: IAB selection issue; this report uses native
cua.getApp('com.google.Chrome')and also affects native apps.
The machine was migrated from another Mac, but app reinstallation and fresh Computer Use component installation did not resolve the issue. Root cause remains unconfirmed. Could the native Mac drag path's button-state/event-source handling on macOS 27 be investigated?
Follow-up: verified foreground/background comparison (2026-09-06)
A temporary read-only event tap now records the frontmost application PID during every native event. With Chrome genuinely frontmost throughout the drag, the failure still reproduces; it also reproduces with another application frontmost. Merely raising a window was not considered proof of foreground activation.
In both cases, captured native down/drag/up events had eventSourceStateID=0 (combined session), flags=0, and both queried HID/combined-session left-button states were false at the observation point. Down/up shared an event number while drag used a different one; drag clickState was zero. We do not interpret global button-state queries alone as proof of the root cause, because directed input and timing may affect state-table observations. The target Chrome still reports pointermove.buttons=0.
Additional isolation: Raycast, Maccy, and MouseBoost Finder extension were stopped and absence verified; failure persisted. The UWST screen-sharing helper was also stopped and failure persisted. No third-party pointing-device driver or virtual mouse was found in the inspected system-extension/HID inventories. These are bounded checks, not proof that all software interactions are excluded.
Independent review did not identify an explicit mouse/drag/tap preference to change. No preference caches or protected App Group contents were cleared. A potentially relevant comparison is Deskflow commit https://github.com/deskflow/deskflow/commit/d082157f (per-button event numbers plus a switch to the session event tap to fix macOS 27 click-to-focus). It is not a confirmed fix for this issue.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the native CUA entry point cua.getApp(...).drag(...) and trace the shared macOS event-injection path described in the report. Use the reduced event logger to compare native dragging with the independent Swift control, then reproduce in Chrome, Safari, Finder, and Notes. Done means native drag movement preserves the primary-button state and file drops or canvas strokes work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100