Appshot fails after ScreenCapture permission: SkyComputerUseService crashes with EXC_BAD_ACCESS on macOS 15.0

Proposed Solution: Appshot ScreenCapture Crash Fix

Root Cause

SkyComputerUseService crashes with EXC_BAD_ACCESS at 0x0000000000000004 (null pointer dereference with small offset) on thread 12 after ScreenCapture permission is granted. Likely TCC permission state race — the permission object is NULL during the propagation window between user granting permission and kernel TCC subsystem fully updating.

Fix

1. TCC Permission Verification: Retry loop with 500ms delay, wait for TCCAccessStatus.authorized
2. Null-Safe Screenshot: Check CGWindowListCreateImage() return value before accessing properties
3. XPC Health Check: Ping service before capture; re-establish connection if dropped
4. Crash Recovery: Show permission guide on failure, generate diagnostics

Key Code Change

func verifyScreenCapturePermission() async throws -> Bool {
    for attempt in 0..<5 {
        let status = TCCAccessStatus(for: .screenCapture)
        if status == .authorized { return true }
        if status == .notDetermined {
            try await Task.sleep(nanoseconds: 500_000_000)
            continue
        }
        throw CaptureError.permissionDenied
    }
    throw CaptureError.permissionTimeout
}

Full solution: solutions/codex-23992-appshot-screencapture-crash-fix.md

Thanks for the analysis. The race-condition explanation matches what I observed: the crash happens right after ScreenCapture permission is granted.

One question: is TCCAccessStatus(for: .screenCapture) intended as pseudocode here, or is there a concrete public macOS API you recommend using? My understanding is that the public path is usually CGPreflightScreenCaptureAccess() / CGRequestScreenCaptureAccess(), plus retrying the actual capture call and nil-checking the returned image/window content.

The proposed fix direction makes sense to me:

• wait/retry after permission grant
• verify capture access before starting screenshot
• nil-check CGWindowListCreateImage() / ScreenCaptureKit results
• recover gracefully if the screenshot service/XPC connection is not ready

If you have a branch or patch for this, I can test it on my machine.

I hit a similar shape while testing long Computer Use sessions. I would separate whether the hot path is transcript rendering/state retention versus a still-running tool loop.

A useful capture set for this failure is:

• Activity Monitor sample of the main app PID while hot
• ps/top snapshots for the main app, helper, and Computer Use helper processes
• whether the active thread contains repeated get_app_state accessibility trees/screenshots
• a restart test against the same thread versus a fresh short thread

If a fresh short thread idles normally but the large Computer Use thread keeps the main app hot, that points more toward main-process transcript/render bookkeeping than macOS permissions or model work.

I keep a Mac agent workstation checklist here that may help rule out setup-layer causes first: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html?utm_source=github&utm_medium=issue&utm_campaign=openai-codex-23992

If someone wants the Mac setup audited instead of doing it manually, I packaged that as a $49 same-day triage service: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/?utm_source=github&utm_medium=issue&utm_campaign=openai-codex-23992

Thanks, this is useful for separating the long-session hot-process case from the immediate ScreenCapture-permission crash.

In my case, the failure I was focused on happens right after granting ScreenCapture permission, so I still want to keep that separate from transcript/render bookkeeping. That said, I agree the diagnostics you listed would help if the app stays hot during long Computer Use sessions.

I can try to capture:

• Activity Monitor sample for the main app PID while hot
• ps / top snapshots for main app, helper, and Computer Use helper
• whether the active thread is repeatedly calling get_app_state / accessibility tree / screenshot capture
• same-thread restart vs fresh short-thread comparison

If I can reproduce the hot-process case separately from the permission crash, I’ll add those details here.

Update after installing today's Codex update:

Codex App is now:

Codex App: 26.527.31326
CFBundleVersion: 3390
macOS: 15.0 (24A5289h)

The Computer Use helper still appears to be the same build:

Codex Computer Use.app
bundle id: com.openai.sky.CUAService
version: 1.0
build: 799

I retested appshot after the update. The issue is still reproducible.

I also tried a clean permission rebuild:

• quit Codex fully
• killed leftover SkyComputerUseService / SkyComputerUseClient processes
• reset ScreenCapture and Microphone TCC entries for:
• com.openai.codex
• com.openai.sky.CUAService
• com.openai.sky.CUAService.cli
• reopened Codex
• pressed the appshot hotkey once

Actual result:

• no new "Open System Settings" permission prompt appeared during that test
• the UI still showed Unable to attach appshot
• a new SkyComputerUseService crash report was generated

Latest crash summary:

SkyComputerUseService-2026-06-01-180125.ips
proc=SkyComputerUseService
parent=Codex
bundle=com.openai.sky.CUAService
version=1.0
build=799
os=macOS 15.0 24A5289h
exception=EXC_BAD_ACCESS
signal=SIGSEGV
subtype=KERN_INVALID_ADDRESS at 0x0000000000000004
faultingThread=0

Codex logs still show the same capture flow shape:

Appshot hotkey pressed hotkey=DoubleCommand
Appshot capture start request finished ... hasResponse=true
Computer Use next-capture-update Apple Event failed ... AESendMessage failed with -600
Computer Use capture worker update poll failed ... AESendMessage failed with -600
Appshot capture settled ... failureReason=update_poll_failed hadAxText=false hadScreenshot=false status=failed

So the main app update to 26.527.31326 does not appear to fix this case. The helper is still com.openai.sky.CUAService 1.0 build 799, and it still crashes before returning the appshot result.