Computer Use loses scrolling/input control across macOS apps #38508

Activity

1. Poole33

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 14, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   computer-use

   on Aug 14, 2026
3. it-yusha commented on Aug 30, 2026

   

   it-yusha

   on Aug 30, 2026

   More actions

   I reproduced this issue specifically with iPhone Mirroring, and a controlled A/B test points to a regression in the current ChatGPT app build.

   Environment

   • macOS: 26.6.2 (25G83), Apple Silicon
   • Current ChatGPT app: 26.825.51511 (build 7377)
   • Immediately previous ChatGPT app: 26.825.41651 (build 7345)
   • Computer Use helper in both tests: 26.828.1000919 (build 1000919)

   Current-build result

   With ChatGPT 26.825.51511:

   • Reading Calculator state succeeded.
   • Clicking a Calculator button succeeded, so Computer Use was not globally broken.
   • Reading a fully connected iPhone Mirroring window succeeded.
   • A harmless tap in the same visible iPhone Mirroring window failed with:

   Computer Use server error -10005: noWindowsAvailable
   

   Restarting iPhone Mirroring and then safely restarting ChatGPT did not resolve it.

   SkyComputerUseService remained alive, and no new helper crash report appeared. This differs from the earlier helper-crash issue where the native pipe closes.

   Controlled previous-build A/B test

   I fully quit the current app and launched the immediately previous official ChatGPT build from a separate temporary directory. I did not overwrite /Applications/ChatGPT.app, run both versions simultaneously, or replace the helper.

   With ChatGPT 26.825.41651 and the same helper build 1000919:

   • Calculator read and click succeeded.
   • iPhone Mirroring read succeeded.
   • One harmless tap succeeded.
   • The iPhone UI visibly changed as expected.
   • noWindowsAvailable did not occur.
   • The helper remained alive and no new crash report appeared.

   I then quit the temporary previous build and reopened the installed current app.

   This suggests a regression between ChatGPT app builds 7345 and 7377, rather than a global Computer Use permission problem or a change in the helper build.

   Temporary diagnostic workaround—not an official rollback feature

   For users who need iPhone Mirroring before a fixed build is released, the immediately previous official archive is still available from OpenAI:

   https://persistent.oaistatic.com/codex-app-prod/ChatGPT-darwin-arm64-26.825.41651.zip
   

   Observed archive details:

   Size:   595252422 bytes
   SHA256: 670d69dab878bd45d70e962c5624e022b8c608f45f704ca6d960b60d819a9b92
   

   I verified ZIP integrity, the OpenAI code signature, and Apple notarization before testing.

   Example verification after extracting to a temporary directory:

   codesign --verify --deep --strict "/private/tmp/chatgpt-41651/ChatGPT.app"
   spctl -a -vv --type execute "/private/tmp/chatgpt-41651/ChatGPT.app"

   Important cautions:

   • This is not a documented or officially supported rollback workflow.
   • Use it only at your own risk.
   • Quit the installed current app completely first.
   • Do not overwrite /Applications/ChatGPT.app.
   • Do not run old and current builds together.
   • Do not replace only the Computer Use helper.
   • Preserve unsent work and verify task/project/CWD state after switching.
   • Quit the temporary build and reopen /Applications/ChatGPT.app to return to the installed version.

   I am sharing this mainly as diagnostic evidence and as a temporary continuity option for affected users. A supported rollback mechanism or a fixed current build would be much safer.
4. diegocantarero commented on Sep 10, 2026

   

   diegocantarero

   on Sep 10, 2026 – with ChatGPT Codex Connector

   More actions

   Additional user-authorized reproduction, 2026-09-10 (macOS). Desktop observed version 26.903.61454; Computer Use helper 26.902.1000968, codesign --verify --deep --strict passed. Activity Monitor initially exposes a window and AX state. Recent reads took 17.434s, 15.055s and 17.944s. A subsequent invocation containing app.click(39) followed by app.getAXState() failed after 52.591s with Computer Use server error -10005: noWindowsAvailable. Because those operations were batched, we cannot establish whether input or readback failed, nor whether the click partially applied. No replay was attempted. T3 Code Nightly separately reproduced noWindowsAvailable after successful reads; an update download was concurrent, not proven causal. Thus a successful read must not be counted as interaction recovery. We need a supported current-build diagnostic/rebind procedure preserving active tasks, rather than repeated app restarts or permission resets. Is this tracked as the same read/input window-binding regression? No raw logs, account identifiers or credentials included.
5. perpetua-engineering commented on Sep 10, 2026

   

   perpetua-engineering

   on Sep 10, 2026

   More actions

   Additional reproduction on Apple Watch Simulator, 2026-09-10. This adds a Simulator target and a clean lifecycle retry to the read/input split described above.

   Environment (installed versions checked after the run):

   • macOS 26.6.2 (25G83), Apple Silicon
   • Desktop app at ChatGPT.app: 26.901.51231 (8109)
   • Xcode 26.6 (24959)
   • Fresh disposable iPhone 16 Pro / iOS 26.2 paired with Apple Watch Series 11 46mm / watchOS 26.2
   • Native app control through mcp__cua_repl.js, cua.getApp("com.apple.iphonesimulator")

   Observed behavior:

   • Computer Use initially completed many successful host-Crown detents and watch-display clicks, with a fresh Simulator host state/screenshot after each action.
   • It then returned Computer Use server error -10005: noWindowsAvailable during Crown input. Separate subsequent screenshot reads still returned the rendered watch window.
   • A read-only application progress oracle remained unchanged after failed input. This supports no observed input effect in these cases; it does not identify the internal failing component.
   • No simulated watch accessibility tree was queried; only the Simulator host shell and visible Crown control were used.

   Bounded recovery results:

   • Raising the window did not resolve the failure.
   • Window > Fit Screen plus refocusing briefly restored input; failures recurred at both fitted and physical sizes.
   • A fresh Computer Use JavaScript session briefly restored input, then the same error returned.
   • Reopening the exact watch window did not resolve it.
   • With only the disposable pair active, restarted Simulator, rebooted both owned devices, waited for boot completion, reopened the watch and relaunched the app. Fresh initial UI appeared and recovery-menu clicks worked. The first Crown action visibly moved selection; the second returned noWindowsAvailable again. A separate progress read showed no change from the failed action.

   A separate attachment observation: attaching to Simulator with no booted device window returned timeoutReached. Booting/opening a disposable phone recovered attachment in an A/B/A/B test, while a benign host app attached normally. Opening a real device window fixes that preflight case but does not prevent the recurring watch-input error above.

   No explicit host-lock diagnosis was returned. We did not test manual mouse/Crown input side-by-side at the instant of failure, so this does not conclusively isolate Computer Use from Simulator input handling. No CoreSimulatorService reset, permission reset, or desktop-version rollback was attempted.

   No raw logs, screenshots, wallet material, private paths or device identifiers attached. The disposable devices and run artifacts were deleted. A supported input-window rebind procedure or targeted diagnostics for the next recurrence would be useful; successful attachment/readback alone did not establish sustained input recovery.
6. RostyslavDzhohola commented on Sep 17, 2026

   

   RostyslavDzhohola

   on Sep 17, 2026

   More actions

   Additional reproduction on 17 September 2026: iPhone Mirroring remains unusable for sustained Computer Use even after reinstalling/updating the desktop app and helper. This is a serious workflow blocker. Please prioritize investigation and provide a supported recovery procedure or a fixed-build reference; repeated refresh/restart/reinstall attempts have not resolved it.

   Environment and upgrade comparison

   Component	Before reinstall	After reinstall
   Desktop app (ChatGPT.app, using Codex)	26.908.70816 (build 9275)	26.911.61220 (build 9647)
   Codex Computer Use helper	26.913.1001067 (build 1001067)	26.913.1001068 (build 1001068)

   • macOS: 27.0, build 26A428.
   • Target: Apple iPhone Mirroring, bundle ID com.apple.ScreenContinuity.
   • Mirrored device model: iPhone 13 Pro Max. iOS version was not collected.
   • Interface: mcp__cua_repl.js, using cua.getApp, screenshot/accessibility reads, click, pressKey, and the exposed window Raise action.
   • I previously used Mirroring successfully and noticed the regression after updating macOS. This is a user-observed timeline, not proof that the OS update caused it; no controlled OS rollback was performed.

   Exact failure and what still works

   The connected phone is visible, and fresh screenshots show the actual iPhone Home Screen or Shortcuts library. The accessibility tree identifies the Mirroring wrapper window (iphone-mirroring-main) and its menus, but provides no useful elements for the iOS controls inside it.

   A coordinate click immediately following a successful read repeatedly fails with:

   Computer Use server error -10005: noWindowsAvailable
   

   Examples include tapping Home Screen Search and the ellipsis/editor button on a shortcut card. Several failures returned in roughly 20–60 ms, before the subsequent readback statement could execute. No requested editor/menu transition was observed.

   In the same session:

   • pressKey('super+3') opens iPhone Spotlight.
   • Typing Shortcuts and pressing Return opens the iPhone Shortcuts library successfully.
   • Clicking the native macOS Mirroring Resume button through its accessibility index can reconnect the phone.
   • The user can manually click through Mirroring and navigate the phone while agent input is unreliable.
   • A few coordinate clicks briefly worked, followed by the same failure. Successful screenshots or one accepted click do not demonstrate sustained recovery.
   • We also saw an inactive-session error and, after refreshing, a message claiming the user changed the target app. That message alone does not establish actual user interference.

   Minimal observed sequence

   const phone = await cua.getApp('com.apple.ScreenContinuity');
   await phone.getAXStateAndScreenshot();
   // Derive x/y from this current screenshot, targeting a harmless visible control.
   await phone.click([x, y]); // frequently throws -10005: noWindowsAvailable

   The same session can subsequently execute keyboard navigation while coordinate input continues failing.

   Recovery attempts and results

   • Refreshed accessibility state and screenshots; reacquired the app target.
   • Reset the Computer Use JavaScript session.
   • Quit/reopened iPhone Mirroring and reconnected the phone.
   • Resumed a paused Mirroring connection: briefly recovered some taps, then failed again.
   • Used the exposed Raise action to foreground the window: one click returned without an exception, but the intended editor did not open; later screenshot framing changed and the tool reported a target-window change.
   • User reinstalled/updated the desktop app; verified both new versions in the table above. Keyboard navigation still worked, but coordinate clicks failed again.

   No privacy-permission reset, helper replacement, OS downgrade, or alternate input-injection workaround was performed. We did not independently verify the current permission toggles, so we are not claiming a completed permissions audit.

   Local helper crash evidence

   A local macOS diagnostic report records SkyComputerUseService crashing during this task at 2026-09-17 13:23:57.7589 -0500, before the reinstall:

   Exception: EXC_CRASH / SIGABRT
   Termination: SIGNAL, code 6, Abort trap: 6
   Faulting thread: 35
   Selected stack frames, in order:
   __pthread_kill
   pthread_kill
   abort
   swift::fatalErrorv(unsigned int, char const*, char*)
   swift::fatalError(unsigned int, char const*, ...)
   -[_TtCs12_SwiftObject doesNotRecognizeSelector:]
   ___forwarding___
   _CF_forwarding_prep_0
   _AXObserverAddNotification
   __processObserverForRemoteProcessNotifications_block_invoke
   

   This proves a helper crash occurred; it does not establish that every subsequent noWindowsAvailable error is caused by that crash. It also differs from the exception reported in #27895. The post-reinstall failures above are separately observed; we have not established a new post-reinstall crash.

   User impact and requested follow-up

   A simple workflow—configure an iPhone shortcut, add it to the Home Screen, and verify its links on the phone—could not be completed by the agent. The shortcut synced successfully, but Home Screen setup and end-to-end phone verification remained blocked by input failures. This consumed repeated attempts and required manual intervention despite the visible app remaining usable by the user.

   Could the maintainers please:

   1. Confirm whether this is the same window-discovery/input-binding regression tracked here and in macOS 26.6.2: coordinate click/drag fails with -10005 noWindowsAvailable in Safari and Krita, but works in TextEdit #43119 / macOS Computer Use: fresh Safari state succeeds, then coordinate click fails with -10005 noWindowsAvailable after app restart #36459.
   2. Specify targeted diagnostics that distinguish an invalid input-window reference, helper lifecycle failure, and an Accessibility compatibility problem.
   3. Provide a supported recovery/rebind procedure that preserves active tasks, or identify a build containing a fix.
   4. Make the action layer recover or return an actionable error when it cannot target a window that the read layer just captured.

   The current behavior is extremely frustrating and makes this feature unreliable for real work. Please treat it as a functional blocker, not merely an enhancement request. No raw crash files, private screenshots, account details, or private task links are included in this comment.
7. andrewldesousa commented on Sep 18, 2026

   

   andrewldesousa

   on Sep 18, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on September 18, 2026, reported with the affected user's authorization.

   Environment:

   • ChatGPT desktop app running a Codex task: 26.915.31945, build 9922 (read from the installed app's Info.plist).
   • macOS 26.4.1, build 25E253.
   • Computer Use through mcp__cua_repl / cua.getApp.

   Observed behavior:

   • iPhone Mirroring (com.apple.ScreenContinuity): app discovery, accessibility-tree reads, screenshots, and keyboard navigation work. Coordinate clicks and coordinate-based scrolling repeatedly fail immediately with Computer Use server error -10005: noWindowsAvailable.
   • System Settings (com.apple.systempreferences): a fresh screenshot succeeds, but a coordinate click on the visible Privacy & Security sidebar item returns the same error. Clicking that same item using its freshly observed accessibility element ID succeeds and opens the correct pane.
   • Native menu selection using accessibility IDs also succeeds in iPhone Mirroring.
   • The user can manually click the mirrored phone normally.

   Representative reproduction:

   1. Acquire System Settings with await cua.getApp('com.apple.systempreferences').
   2. Read the current accessibility state and capture a screenshot.
   3. Click a visible sidebar item using screenshot-derived coordinates. In this window layout, await settings.click([106, 787]) returned -10005: noWindowsAvailable.
   4. Refresh the accessibility state and click the same Privacy & Security item by its current element ID. This succeeds.
   5. Acquire iPhone Mirroring and read its screen; coordinate clicks and phone.scroll([x, y], 'down', 0.5) likewise fail with the same error.

   Troubleshooting verified:

   • Codex Computer Use is enabled in both macOS Accessibility and Screen & System Audio Recording permissions. These were inspected directly in System Settings; no permission changes were made.
   • Resetting the cua_repl session and reacquiring app handles did not fix it.
   • The user restarted both the desktop app and iPhone Mirroring; the failure persisted afterward.
   • Raising the Mirroring window did not fix it.

   This adds a reproduction in System Settings that distinguishes successful accessibility-element activation from failing coordinate input. Root cause is not established. Expected behavior is for coordinate input to target the same visible window that the tool can already capture and inspect.