Computer Use 1.0.1000366: SkyComputerUseService SIGTRAP on exact-path SwiftUI accessibility capture

Summary

On ChatGPT Desktop 26.707.41301 with bundled Computer Use plugin 1.0.1000366, SkyComputerUseService reproducibly crashes with EXC_BREAKPOINT / SIGTRAP when get_app_state targets an exact-path SwiftUI macOS app. Finder capture succeeds immediately beforehand. The failure occurs while the sole live helper is the Desktop-managed runtime with matching signed identity; no plugin-cache fallback or DYLD compatibility failure is involved.

This appears related to #28933, but this reproduction additionally isolates helper routing and duplicate target-app installations.

Environment

• macOS 26.5.2 (25F84)
• ChatGPT Desktop 26.707.41301 (5103)
• bundled Computer Use plugin 1.0.1000366
• SkyComputerUseService 26.708.1000366 (1000366)
• helper Team ID: 2DC432GLL2
• target: Vocello / QwenVoice, SwiftUI macOS app

Controlled reproduction

1. Restart ChatGPT Desktop and open a fresh Codex task.
2. Enable the bundled Computer Use plugin and Node REPL.
3. Load the plugin-owned computer-use-client.mjs wrapper.
4. Call sky.list_apps().
5. Verify exactly one SkyComputerUseService process is running from:

$HOME/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

1. Verify the Desktop-managed runtime, ChatGPT-bundled source, and installed plugin-cache source match on bundle ID, version/build, signing team, designated requirement, code-sign validity, and executable SHA-256.
2. Call:

``js
await sky.get_app_state({
app: "/System/Library/CoreServices/Finder.app",
disableDiff: true
})
``
Finder returns accessibility text and a screenshot.

1. Call exactly once:

``js
await sky.get_app_state({
app: "<repo>/build/Vocello.app",
disableDiff: true
})
``

Expected

The exact-path app returns accessibility text and a screenshot while the same Desktop-managed helper remains alive.

Actual

The call fails after several seconds with:

Sky Computer Use native pipe closed before response

A new SkyComputerUseService-*.ips report is generated. The helper exits and becomes an unreaped Desktop child. Exactly one target app process was launched from the requested absolute path; it was stopped afterward. No display-name or bundle-ID fallback was attempted.

The crash report contains:

• EXC_BREAKPOINT
• SIGTRAP
• faulting queue: com.apple.root.user-initiated-qos.cooperative
• multiple AXNotificationObserver threads, including observers for the exact target PID
• no OS_REASON_DYLD
• no missing _swift_task_addPriorityEscalationHandler symbol

The latest crash frame is in the helper binary and is not symbolicated in the report.

Routing and identity evidence

At the start of the reproduction:

• service process count: 1
• routing status: expected
• Desktop-managed runtime running: true
• plugin-cache fallback running: false
• duplicate runtime detected: false
• unknown service path: false
• stale client set: false
• zombie children: 0
• source/runtime identity match: true
• executable SHA-256: b47f564a5dee10fc8f21f6c8b2aee934b30ad04feee33746053253b3661df4e0

The Node REPL configuration exposes the versioned plugin-cache app through SKY_CUA_SERVICE_PATH, while this Desktop build runs the live managed helper from $HOME/.codex/computer-use. This reproduction did not use the plugin-cache fallback route.

Duplicate-app isolation

The machine originally had three Vocello products sharing com.qwenvoice.app: an installed release, a DerivedData release product, and the exact build/Vocello.app target.

For the second controlled reproduction:

1. The installed and DerivedData bundles were physically moved into a hidden quarantine without deletion.
2. build/Vocello.app was the only physical target left.
3. Computer Use's list_apps() still returned three cached entries.
4. Finder capture passed.
5. The first exact-path Vocello observation crashed the Desktop-managed helper with the same signature.

The quarantined apps were restored afterward. This shows that duplicate physical installations are not required to trigger the crash.

Additional observations

• Repeated authorization prompts were previously observed even though Accessibility and Screen & System Audio Recording were enabled.
• Two earlier plugin-cache launches produced the same EXC_BREAKPOINT / SIGTRAP class, but the controlled Desktop-managed reproduction shows fallback routing is not a necessary cause.
• Raw crash reports are not attached because they contain local paths. A sanitized excerpt or full report can be provided if requested.

Requested behavior

Please investigate the accessibility-capture crash and expose it as a specific error rather than the generic inactive/native-pipe failure. It would also help to clarify:

1. Whether exact-path targeting is expected to isolate multiple cached entries sharing a bundle identifier.
2. The supported ownership contract between the plugin-cache source and the Desktop-managed runtime copy.
3. Whether a symbolicated helper build or diagnostic mode can be provided for this crash class.