Computer Use enabled on new Mac, but native app API absent and onboarding did not run

Environment

• Date: 2026-09-10
• Newly configured dedicated Mac mini.
• ChatGPT desktop: 26.903.71938, build 8576 (installed Info.plist).
• macOS: 15.3.1, build 24D70 (sw_vers).
• Target application: KiCad PCB Editor 10.0.6.
• Local task initially created through CLI and subsequently made visible in the desktop app.

User-reported setup

Computer Use was already switched on when ChatGPT was installed on this new machine. The expected interactive setup flow directing the user to macOS permissions did not occur. All available Computer Use switches are enabled. The user manually enabled Accessibility for ChatGPT. There is no PCB Editor entry in the Computer Use section.

Observed sequence

1. Earlier in the same task, cua.getState() returned native running applications and Chrome tabs.
2. Calling cua.getApp("/Applications/KiCad/PCB Editor.app") returned: Computer Use was not approved to use PCB Editor.
3. After the task became visible in the desktop app and the user enabled Accessibility, the same call returned: cua.getApp is not a function.
4. Reset the CUA JavaScript kernel using mcp__cua_repl.js_reset.
5. Called cua.getState() in the fresh kernel: apps was [], while Chrome and the in-app browser were listed.
6. Retried cua.getApp("/Applications/KiCad/PCB Editor.app"): still cua.getApp is not a function.
7. The tool-provided API documentation still advertises cua.getApp() and cua.listApps(). Browser-tab creation and GitHub page interaction work.
8. While preparing this report in a later turn, cua.getState() again returned native applications. Native KiCad control has not yet been retested following that change. This suggests changing capability availability across turns, rather than proving a persistent absence.

Expected

The app should validate this device’s native Computer Use prerequisites and run or offer the missing onboarding steps. If native control is enabled, the documented getApp API should exist and allow the normal application-access flow. If prerequisites are missing, expose a specific actionable diagnostic instead of advertising an absent API or returning an empty native-app inventory without explanation.

Actual / impact

Native desktop control was unavailable despite enabled settings and manually granted Accessibility. The agent could not reach KiCad to perform requested interactive PCB routing. Resetting the tool kernel did not resolve it at the time.

Hypothesis, not established cause

Possible mismatch between account/global Computer Use enablement, per-device onboarding/permission state, and the native provider registered for this task. The CLI-created-to-desktop-visible transition may also be relevant. No registry mismatch or root cause has been proven, and Screen Recording authorization has not been independently verified.

Requested investigation

Check per-device onboarding completion, native provider registration/capability advertisement, permission refresh after macOS Accessibility changes, and whether CLI-created tasks adopt the desktop native provider correctly. Ensure settings distinguish feature enablement from device readiness and offer recovery when onboarding was skipped.

No board files, credentials, full transcripts, browser history, or raw application logs are included.

Start by reproducing the reported sequence: compare cua.getState(), cua.getApp(), and cua.listApps() before and after resetting the JavaScript kernel, granting Accessibility, and moving the task from CLI to the desktop app. Trace device onboarding, native provider registration, and permission refresh; done means native capability availability is consistent and missing prerequisites produce an actionable diagnostic.