›_ Codex Issues
Codex Issues / #32293

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

Open 💬 2 comments Opened Jul 11, 2026 by PowerBeef

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.

View original on GitHub ↗

2 Comments

PowerBeef · 1 month ago

Additional crash differential and bounds-trap evidence

I compared all four local SkyComputerUseService crash reports and their corresponding unified logs. They share one deterministic fingerprint:

  • Helper: 26.708.1000366 (1000366)
  • UUID: 61C0B615-7F27-3A07-8D97-77ABC7139236
  • Team ID: 2DC432GLL2
  • Executable SHA-256: b47f564a5dee10fc8f21f6c8b2aee934b30ad04feee33746053253b3661df4e0
  • Exception: EXC_BREAKPOINT / SIGTRAP
  • Queue: com.apple.root.user-initiated-qos.cooperative

The normalized 20-frame helper stack is identical in all four reports:

0x66d820, 0x6bec0c, 0x6a62b4, 0x6a5f2c,
0x6a5f90 ×3, 0x1bce70, 0x1bbbfc, 0x1bdac4,
0x1b8114, 0x6b93e4, 0x5f380, 0x6b84d4,
0x1b4f14, 0x1b8139, 0x59d9c1, 0x1b8121,
0x86671, 0xce45

Disassembly around the first frame shows a deterministic bounds check:

ldr  x8, [x19, #0x10]   ; current collection count
cmp  x21, x8             ; requested index
b.hs 0x10066d820         ; trap when index >= count
...
sub  x25, x8, #0x1       ; decrement count
...
str  x25, [x19, #0x10]   ; store new count
...
0x10066d820:
brk  #0x1

Every report has:

x21 = 5
x8  = 4

The surrounding code checks uniqueness, validates the index, decrements the count, moves an element, shifts the tail, and stores the new count. It is consistent with a specialized Swift collection-removal path. At minimum, the immediate failure is certain: the helper traps because it attempts an operation at index 5 while the collection count is 4.

There is also a direct thread correlation between the crash reports and AccessibilitySupport logs. In every reproduction, the .ips faulting thread ID equals the unified-log TID that emitted:

[TransformedUIElement] Error Domain=AccessibilitySupport.UIElementError Code=0

immediately before termination:

fault TID 0x54a1  -> TransformedUIElement Code=0 on TID 0x54a1
fault TID 0x5bab  -> TransformedUIElement Code=0 on TID 0x5bab
fault TID 0x2b277 -> TransformedUIElement Code=0 on TID 0x2b277
fault TID 0x36ff6 -> TransformedUIElement Code=0 on TID 0x36ff6

In the latest controlled run, AccessibilitySupport finished its settle wait and returned a new tree, ScreenCaptureKit began enumerating windows on another thread, the faulting AX worker emitted another TransformedUIElement Code=0, and then hit the bounds trap. This supports an accessibility-tree transformation/invalidation defect rather than a screenshot or permission failure.

The target app's persisted initial screen was also identified. Both its production and debug preferences restored Settings during every cold capture. That SwiftUI screen contains:

  • a grouped Form with multiple Section containers;
  • Toggle, segmented Picker, and two complex LabeledContent rows;
  • dynamically refreshed model rows;
  • nested .accessibilityElement(children: .contain) groups;
  • a model refresh followed by a first-responder reset after 50 ms.

This overlaps with the minimal Form / Toggle / LabeledContent reproduction in #28933. It is not yet proof that this particular subtree is the root trigger, but it is a strong candidate for an AX-tree mutation or unsupported-topology bisect.

Could OpenAI provide one of the following?

  1. A matching dSYM or symbolicated trace for helper UUID 61C0…9236.
  2. A diagnostic build that records the failing AX element path, tree revision, or transaction operation.
  3. A defensive fix that revalidates/re-resolves the index after tree invalidation—or restarts from a fresh tree snapshot—instead of reaching brk #0x1.

The same fingerprint occurred through both the former plugin-cache route and the Desktop-managed runtime, including after duplicate physical target bundles were removed from the test environment. Routing and duplicate installations therefore do not appear necessary for this bounds failure.

PowerBeef · 1 month ago

Fresh-task differential from the same Vocello investigation:

  • ChatGPT Desktop 26.707.41301 (5103), Computer Use plugin 1.0.1000366, helper 26.708.1000366 (1000366), UUID 61C0B615-7F27-3A07-8D97-77ABC7139236, SHA-256 b47f564a5dee10fc8f21f6c8b2aee934b30ad04feee33746053253b3661df4e0.
  • The fresh task used the plugin Node REPL route with exactly one Desktop-managed helper. No plugin-cache fallback, duplicate helper, stale client, zombie, or unknown route was present.
  • Finder accessibility and screenshot capture succeeded first.
  • I prelaunched only the exact repository build/Vocello.app with a debug-only, non-persisting initial screen of History and waited for one stable process/window.
  • One exact-path get_app_state observation returned a complete History accessibility tree (1,815 characters) and a screenshot URL.
  • The helper retained the same PID, UUID, and hash. The app retained one exact-path PID. No new SkyComputerUseService .ips report or native-pipe closure occurred.
  • Capture returned to Finder before cleanup, which left zero Vocello processes and the same helper running.

Interpretation: a prelaunched, settled History surface is transformable by helper 1000366. This narrows the reproduction but does not clear the helper or prove the app-side candidate. The four prior failures cold-restored Settings; this run changed both attachment timing and initial surface. The Settings focus-reset removal still needs a one-observation A/B in a separate fresh helper session. No model inspection, action, generation, suite, or benchmark was attempted.