[macOS][Computer Use] Accessibility scan crashes Qt Creator 20.0.0 with libqcocoa SIGSEGV

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.31414

What subscription do you have?

Unknown / not checked

What platform is your computer?

Darwin 25.6.0 arm64 arm; macOS 26.6.2 (25G83), Apple Silicon

What issue are you seeing?

When Codex/ChatGPT Computer Use accessibility observation is active, opening Qt Creator can crash the target Qt application itself on macOS. This is distinct from the Computer Use helper crashing.

Observed environment:

• Qt Creator 20.0.0, bundled Qt 6.11.1, running natively on arm64
• macOS 26.6.2 (25G83)
• The Qt Creator app is Apple-signed/notarized; no user-installed third-party Qt Creator plugins were found

Observed crash signature:

• EXC_BAD_ACCESS / SIGSEGV on the main thread
• First frame: libqcocoa.dylib + 554888 (0x87788)
• Next frames: NSAccessibilityAttributeAccessorInfo getAttributeValue:, accessibilityArrayAttributeCount:, and AXCopyHierarchy
• Symbol inspection places the Qt frame in QMacAccessibilityElement::accessibilitySelectedChildren; the selected-child accessible interface pointer appears invalid/stale
• Six crashes occurred within a few minutes on 2026-08-28, with the same signature already present on 2026-08-23
• At the time of the first crash, the macOS unified log showed SkyComputerUseService issuing WindowUIElement/ApplicationUIElement/TransformedUIElement accessibility queries

The current evidence strongly suggests that an accessibility-tree query from Computer Use exposes a Qt Cocoa accessibility lifetime/use-after-free bug. The exact A/B with Computer Use disabled has not yet been run.

Related reports:

• #28933 and #34432: Computer Use helper crashes while traversing specific macOS accessibility trees
• #41327: Computer Use helper crashes on the first action after get_app_state
• This report differs because the inspected Qt Creator process terminates; SkyComputerUseService remains the suspected trigger.

No full .ips file is attached because it contains local paths and identifiers. A sanitized crash excerpt can be provided if needed.

What steps can reproduce the bug?

1. On an Apple Silicon Mac running macOS 26.6.2, run Codex desktop with Computer Use/Computer History accessibility observation enabled.
2. Launch Qt Creator 20.0.0 (bundled Qt 6.11.1).
3. Use Open Project and select a CMakeLists.txt from a Qt Quick/CMake project, or reopen a recent project.
4. Within a few seconds, Qt Creator exits and macOS reports that it unexpectedly quit. Repeated relaunches can also crash while the accessibility tree is being queried.
5. Inspect the Qt Creator crash report and observe the libqcocoa -> NSAccessibility -> AXCopyHierarchy signature described above.

What is the expected behavior?

Computer Use should not terminate a target application while reading its accessibility tree. If a target exposes a stale or unsupported accessibility node, the observer should return a controlled error or skip that subtree; Qt Creator should remain running.

Additional information

The project itself passed static configuration checks: CMake/Kit paths were valid, the project settings XML parsed successfully, and the crash stack contained no CMake, ProjectExplorer, compiler, or project-source frames. Pausing or excluding Qt Creator from Computer Use observation is the current workaround to test the suspected trigger.

Start with the Computer Use accessibility observation path and the SkyComputerUseService queries described in the report. Reproduce with Computer Use enabled and disabled against Qt Creator, then inspect the sanitized crash excerpt if available; done means identifying whether Codex can avoid terminating the target or confirming that the failure is confined to Qt's accessibility handling.