macOS Appshot shows generic "Unable to attach appshot" when Computer Use blocks a disallowed URL after capture

What happened?

On macOS Codex Desktop, Appshot can fail with the generic user-facing toast:

Unable to attach appshot

In the failing case, local diagnostics showed that Appshot had already collected metadata, accessibility text, and a screenshot, then settled as native_service_failed.

The more specific underlying reason was that Computer Use stopped after detecting a disallowed URL. The page URL itself is intentionally omitted here because it was a work-related enterprise/admin login page.

This makes the failure look like a native service or permissions problem, even though the actual cause appears to be URL policy enforcement.

Environment

macOS: 26.3.1
Codex Desktop: 26.527.31326, build 3390
Computer Use helper: com.openai.sky.CUAService 1.0, build 799
Observed with: Safari

Evidence pattern

Codex app log pattern:

Appshot target found for Safari
Appshot capture update received: metadata
Appshot capture update received: axText
Appshot capture update received: screenshot
Appshot capture settled: failureReason=native_service_failed hadAxText=true hadScreenshot=true status=failed

System log pattern around the same timestamp:

Computer Use stopped due to encountering a disallowed URL: [redacted work-related enterprise/admin login URL]

TCC did not appear to deny the request. The same Codex install can successfully attach Appshots for other apps/pages, so this does not appear to be a global Screen Recording / Accessibility permission failure.

Expected behavior

If Appshot is blocked because the current page URL is disallowed, Codex should surface a specific user-facing reason, for example:

Unable to attach appshot because this page is restricted by URL policy.

The internal failure reason should also distinguish disallowed_url or similar from native_service_failed.

Actual behavior

The user only sees:

Unable to attach appshot

The app log records a generic native-service failure after metadata, AX text, and screenshot have already been collected.

That sends the user toward permission resets, restarts, reinstalling, or browser-specific debugging, even though the capture itself has already succeeded.

Related issues / prior search

I searched recent public issues and did not find this exact disallowed URL Appshot failure mode.

Related but different:

• #25269: same Codex Desktop version and helper build, but failure mode is captureNotFound / update_poll_failed before any AX text or screenshot is available.
• #25271: shows Computer Use URL-confidence / URL-policy enforcement can stop execution, but it is Windows + Chrome and not Appshot.
• #24775 / #23992: broader Appshot / SkyComputerUseService failures, but not this policy-block-after-capture case.

Why this matters

This is probably working-as-designed from a policy standpoint, but the current error classification makes it hard to diagnose. The UI and app logs imply a native service failure while lower-level diagnostics show a URL policy block.