›_ Codex Issues
Codex Issues / #25269

macOS Desktop Appshot fails: Unable to attach appshot, captureNotFound after start succeeds

Open 💬 9 comments Opened May 30, 2026 by cuiqingwei
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

This is a Codex Desktop macOS issue, not a Codex CLI issue.

Environment

  • macOS: 26.5, build 25F71
  • Codex Desktop: 26.527.31326, build 3390
  • Computer Use helper: com.openai.sky.CUAService, version 1.0, build 799

Symptom

When using Appshot from Codex Desktop, the screenshot appears to be taken, but Codex shows:

Unable to attach appshot

No appshot attachment is added to the conversation.

Reproduction

  1. Open Codex Desktop.
  2. Use Appshot / Attach app screenshot.
  3. Try with Finder or Zed as the target app.
  4. Codex shows Unable to attach appshot.

The failure is not limited to one target app. It has reproduced with:

  • Finder, bundle identifier com.apple.finder
  • Zed, bundle identifier dev.zed.Zed

Key Log Pattern

Latest observed log pattern:

Appshot hotkey pressed
target app found
capture request created
capture start request sent
capture worker received start
capture worker finished start with hasResponse=true
next-capture-update Apple Event failed
Codex Computer Use Apple Event error -10005: captureNotFound(requestID: "...")
capture settled failureReason=update_poll_failed hadAxText=false hadScreenshot=false status=failed

Concrete latest example:

2026-05-30T12:07:41.138Z requestId=8371604f-c1fb-491b-9dea-bbfb60bcb09e target Finder
2026-05-30T12:07:41.514Z capture start finished hasResponse=true
2026-05-30T12:07:42.026Z next-capture-update Apple Event failed captureNotFound
2026-05-30T12:07:42.027Z capture settled failureReason=update_poll_failed hadAxText=false hadScreenshot=false

Relevant logs are under:

~/Library/Logs/com.openai.codex/2026/05/30/

Especially:

codex-desktop-7f1787c9-5613-45e2-b949-61aef4129d42-17469-t0-i1-120154-0.log
codex-desktop-7f1787c9-5613-45e2-b949-61aef4129d42-17469-t2-i1-120212-0.log

Local Checks Already Performed

The following local causes were tested or ruled out:

  • Codex was updated/reinstalled. Issue persisted.
  • Full Disk Access was already granted to Codex.
  • Disk write checks succeeded for:
  • ~/.codex
  • ~/Library/Application Support/Codex
  • $TMPDIR
  • The issue reproduces on Finder, so it is not target-app specific.
  • Quarantine and stale helper duplicate cleanup were attempted.
  • Computer Use helper rebuild/reset was attempted.
  • Duplicate SkyComputerUseService processes were killed.

After killing helper processes, Codex immediately spawned many new unmanaged helper instances again, and Appshot still failed with the same captureNotFound pattern.

Important Process Observation

Multiple SkyComputerUseService processes were observed, all parented by the Codex app process:

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

launchctl showed them as unmanaged processes such as:

com.apple.xpc.launchd.unmanaged.SkyComputerUseS.<pid>

This suggests the helpers are spawned directly by Codex rather than managed by a normal LaunchAgent.

Current Diagnosis

This does not look like a macOS permission, disk write, reinstall, or target app problem.

The capture start request succeeds, but the subsequent capture update request fails because the Computer Use bridge cannot find the request ID it just created. The likely failure is inside the Codex Desktop Appshot bridge or Computer Use helper state/routing.

Working hypothesis:

The Appshot start request and update polling request are routed to different helper instances, or the helper loses its in-memory capture registry before Codex polls for the result.

This appears to be a product bug in Codex Desktop Appshot / Computer Use helper build 799 on macOS 26.5.

Expected Fix

Needs a Codex Desktop / Computer Use helper update that fixes Appshot capture request tracking.

Until then, the reliable workaround is to use a normal screenshot file attachment:

  1. Take a screenshot with macOS.
  2. Attach the image via Add photos & files.

This avoids the Appshot bridge path that is currently failing.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23992
  • #24775

Powered by Codex Action

cuiqingwei · 1 month ago

I reviewed the duplicate suggestions from the bot.

#23992 looks related, but that report appears to involve SkyComputerUseService crashing / Apple Event -600. This issue has a different failure mode: capture start succeeds with hasResponse=true, then update polling fails with Apple Event -10005 and captureNotFound(requestID: ...), and no screenshot or AX text is returned.

#24775 also appears related, but this report includes the newer captureNotFound evidence and process observation on Codex Desktop 26.527.31326 / macOS 26.5.

So this may be the same Appshot / Computer Use subsystem, but it is not exactly the same observable failure.

cuiqingwei · 1 month ago

Update: still reproducible on the latest stable Codex Desktop available to me as of 2026-06-14.

Environment:

  • macOS 26.5.1 (25F80), Apple Silicon
  • Codex Desktop 26.609.41114 (build 3888)
  • Computer Use helper 1.0 (build 809)

New reproduction:

2026-06-14T03:01:38.326Z requestId=6e415de4-31d6-4df5-8dfc-21a43f04f8ff
2026-06-14T03:01:38.676Z capture start finished hasResponse=true
2026-06-14T03:01:39.074Z next-capture-update failed: -10005 captureNotFound
2026-06-14T03:01:39.076Z settled: update_poll_failed hadScreenshot=false hadAxText=false

Additional findings:

  • The installed helper is byte-for-byte identical to the helper bundled with Codex.app; both signatures and notarization validate.
  • LaunchServices was cleaned so only the current helper path is registered. The failure remains.
  • For one Appshot request, Codex directly spawns separate SkyComputerUseService processes for capture start and update polling. Pre-launching one helper does not change this behavior. This strongly supports the hypothesis that request state is stored in one helper process while polling is routed to another.
  • Helper build 809 has also produced local EXC_BREAKPOINT/SIGTRAP crash reports around -[NSWindow windowNumber], although this specific reproduction reaches captureNotFound rather than reporting a crash.

This is therefore still present after several Desktop releases and does not appear to be a disk permission, TCC permission, stale registration, damaged install, or target-app issue. Please route this to the Codex Desktop / Computer Use owners; the likely fix is to reuse one service instance or make capture request state available to the polling instance.

cuiqingwei · 1 month ago

Update: I performed a clean reinstall of Codex Desktop and Computer Use, without restoring my previous Codex state first. The issue still reproduces.

This rules out stale local state, old Computer Use helper files, cached app data, and permission drift as the root cause.

The previous local evidence still matches the current behavior: one Appshot attempt can spawn multiple SkyComputerUseService processes, and the helper logs socket lock contention:

socket lock is unavailable errno=35

So this appears to be a Codex Desktop / Computer Use multi-process IPC or request-state bug, not a user-side install or permission problem.

jiagenli · 20 days ago

Additional reproduction on newer Codex Desktop build

I am seeing the same captureNotFound failure mode on a newer Codex Desktop build.

Environment

  • Codex Desktop: 26.623.70822, build 4559
  • App bundle: com.openai.codex
  • Bundled app-server Codex CLI: codex-cli 0.142.4
  • Shell Codex CLI: codex-cli 0.142.0
  • macOS: Darwin 24.6.0 arm64
  • Computer Use helper: com.openai.sky.CUAService, version 1.0, build 857
  • Target app during repro: IntelliJ IDEA, bundle identifier com.jetbrains.intellij

User-visible symptom

Every Appshot attempt fails with the toast:

Unable to attach appshot

Plain image attachment still works. The failing path appears specific to Codex Desktop Appshot / Computer Use capture, not general image upload.

Reproduction

  1. Open Codex Desktop.
  2. Bring IntelliJ IDEA to the front.
  3. Press the Appshot hotkey (DoubleCommand).
  4. Observe that Codex shows Unable to attach appshot and no appshot is attached.

Local repair attempts already tried

The issue still reproduces after:

  • Re-signing in to ChatGPT inside Codex Desktop.
  • Fully restarting Codex.
  • Killing SkyComputerUseService, SkyComputerUseClient, and bare-modifier-monitor.
  • Resetting and re-granting ScreenCapture and Accessibility permissions for:
  • com.openai.codex
  • com.openai.sky.CUAService
  • Reopening Codex and retrying Appshot.

Log evidence

The latest attempts show the same pattern as this issue: start succeeds, but the update poll cannot find the capture request.

2026-06-30T08:00:39.812Z info Launching app buildFlavor=prod platform=darwin
2026-06-30T08:00:40.511Z info Registered appshot hotkey hotkey=DoubleCommand

2026-06-30T08:00:48.305Z warning [computer-use-capture-native-bridge]
Computer Use next-capture-update Apple Event failed elapsedMs=196
errorMessage="Codex Computer Use Apple Event error -10005:
captureNotFound(requestID: \"8f176e3b-f8e1-4bb2-bf78-c776b9584e63\")"

2026-06-30T08:00:48.305Z warning [computer-use-capture-worker]
Computer Use capture worker update poll failed
errorMessage="Codex Computer Use Apple Event error -10005:
captureNotFound(requestID: \"8f176e3b-f8e1-4bb2-bf78-c776b9584e63\")"

Earlier attempts from the same session show the capture start path completing before the failed update poll:

Appshot hotkey pressed hotkey=DoubleCommand
Appshot capture start request finished elapsedMs=968 hasResponse=true
Appshot capture settled elapsedMs=1554 failureReason=update_poll_failed
hadAxText=false hadScreenshot=false permissionGrantState=undefined
status=failed

Diagnosis

This still looks like the Appshot start request and update polling request are not reaching the same capture registry/helper state. The helper reports that capture has started, but immediately afterward next-capture-update cannot find the request ID.

That makes the issue look unlikely to be caused by:

  • macOS Screen Recording permission alone
  • Accessibility permission alone
  • target app-specific restrictions
  • generic image upload failure
  • expired ChatGPT auth alone

Expected behavior

After the capture start request succeeds, the update polling path should find the same request ID and return screenshot/AX-text updates, or Codex should surface a more specific recovery/error state if the helper lost the request.

---
This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated

Liu-Lin-Hai · 10 days ago

I am seeing the same issue immediately after upgrading from the Codex desktop app to the ChatGPT desktop app today.

Environment

  • Apple M4 (Apple Silicon)
  • macOS 15.5
  • ChatGPT desktop app: 26.707.31428

Reproduction

  1. Bring Finder or Safari to the foreground.
  2. Trigger Appshot.
  3. The app shows: Unable to attach appshot.

Checks already completed

  • Screen & System Audio Recording is enabled for both ChatGPT and Codex Computer Use.
  • Accessibility is enabled for both ChatGPT and Codex Computer Use.
  • I fully restarted the app.
  • The issue reproduces with both Finder and Safari, so it is not target-app-specific.

I can provide a screenshot of the error toast if helpful.

Livijn · 10 days ago

I am getting this atm too

irvineacosta · 9 days ago

I’m seeing the same user-facing issue after the Codex -> ChatGPT desktop migration, but with a crash signature from the Computer Use helper.

Environment:
Apple Silicon
macOS 15.7.7 (24G720)
ChatGPT desktop app: 26.707.41301
Computer Use helper: 26.708.1000366

Behavior:

  • Trigger Appshot from ChatGPT.
  • It waits briefly, then shows “Unable to attach appshot.”
  • Reproduces regardless of target app.
  • Permissions are already granted.
  • Restarting and resetting permissions did not resolve it.

Crash logs:
SkyComputerUseService and SkyComputerUseClient crash at launch with:

DYLD Symbol missing: _swift_task_addPriorityEscalationHandler
Expected in: /usr/lib/swift/libswift_Concurrency.dylib

So in my case the Appshot helper appears to fail before any capture permission prompt or target-app attachment step.

hwanseoc · 6 days ago

Not sure if this will work for everyone, but the cause of my appshots breaking was I was symlinking ~/.codex some other directory. Replacing my symlinked ~/.codex with a real directory and clearing old Computer Use registrations fixed it. After restarting ChatGPT it worked again