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

[Kendell-wkp]

What version of the Codex App are you using?

Codex App: 26.519.22136 (CFBundleVersion 3003)
Computer Use helper: com.openai.sky.CUAService, version 1.0 build 799

What platform is your computer?

macOS 15.0 (24A5289h), Apple Silicon (MacBookPro18,1)

What issue are you seeing?

The built-in appshot shortcut fails with the UI error:

Unable to attach appshot

After manually adding Codex Computer Use.app to System Settings > Privacy & Security > Screen & System Audio Recording and enabling it, macOS now shows the permission prompt:

“Codex” can access this computer's screen and audio. Continue to allow access?

Clicking Continue/Allow does not fix the issue. Codex still reports Unable to attach appshot.

Expected behavior

After ScreenCapture and Accessibility permissions are granted, pressing the appshot hotkey should capture the frontmost app/window and attach the appshot to the Codex thread.

Actual behavior

The appshot capture request starts, but the native Computer Use service crashes before returning screenshot/AX content. Codex then fails polling the capture update and shows Unable to attach appshot.

Reproduction steps

1. Install/update Codex App to 26.519.22136.
2. Enable Accessibility for Codex / Codex Computer Use.
3. Manually add and enable Codex Computer Use.app for Screen & System Audio Recording.
4. Quit and reopen Codex.
5. Press the appshot hotkey (DoubleCommand).
6. macOS permission prompt appears; click Continue/Allow.
7. Codex shows Unable to attach appshot.
8. A new SkyComputerUseService-*.ips crash report is generated.

Permission state verified

System TCC database shows permissions allowed:

kTCCServiceAccessibility | com.openai.codex | auth_value=2
kTCCServiceAccessibility | com.openai.sky.CUAService | auth_value=2
kTCCServiceScreenCapture | com.openai.codex | auth_value=2
kTCCServiceScreenCapture | com.openai.sky.CUAService | auth_value=2

Codex log evidence

After the hotkey is pressed, Codex starts the capture successfully:

Appshot hotkey pressed hotkey=DoubleCommand
Appshot capture start request finished elapsedMs=375 hasResponse=true

Then polling the capture update fails because the native service is gone:

Computer Use next-capture-update Apple Event failed elapsedMs=2066 errorMessage="AESendMessage failed with -600"
Computer Use capture worker update poll failed errorMessage="AESendMessage failed with -600"
Appshot capture settled ... hadAxText=false hadScreenshot=false ... status=failed

Crash report summary

Latest crash report observed:

SkyComputerUseService-2026-05-22-111125.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=12

Things already tried

• Quit and reopened Codex after granting permissions.
• Reset ScreenCapture TCC entries and re-granted permissions.
• Verified the helper app exists at the expected path.
• Verified the helper binary is not obviously corrupted: codesign verification passed and installed/cache/bundled copies matched by checksum.
• Temporarily tested with third-party HAL audio drivers disabled, then restored them. The crash still occurred, so this does not appear to be caused by those drivers.

Notes

Before ScreenCapture was manually granted, the same feature failed earlier in the capture flow. After granting ScreenCapture, the flow progresses to capture start request finished hasResponse=true, but SkyComputerUseService still crashes before returning any screenshot. This suggests a native Computer Use / appshot capture crash rather than a missing permission toggle.

I can provide the full .ips crash report through a private/support channel if needed, but I am not including it here to avoid exposing local machine paths or identifiers.

[jshaofa-ui]

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

[Kendell-wkp]

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.

[IgorGanapolsky]

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

[Kendell-wkp]

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.