Vision OCR fails in sandboxed Python with CoreVideo CVPixelBuffer error (-6662), works unsandboxed

Vision OCR fails in Codex sandboxed Python process with CoreVideo CVPixelBuffer error (-6662), but works unsandboxed on the same images

Summary

Apple Vision OCR (VNRecognizeTextRequest) fails inside the Codex sandboxed Python process when processing local images (both extracted JPG frames and local PNG screenshots), returning:

• NSOSStatusErrorDomain Code=-6662
• Failed to create CVPixelBuffer ... Format = '420f'

The same code, same Python venv, and same image files work in a normal terminal (unsandboxed) process.

This blocks reliable offline OCR evaluation in Codex unless run outside the sandbox (or with workarounds like warm-up + external execution).

Environment

• Codex desktop app environment (sandboxed process)
• macOS (Darwin 25.3.0 arm64)
• Python from local venv: .venv/bin/python3
• Vision via PyObjC (pyobjc-framework-Vision, pyobjc-framework-Quartz)
• OpenCV used to load images (cv2.imread / cv2.imdecode)

Observed behavior

Inside Codex sandboxed Python:

• Vision.VNImageRequestHandler.performRequests_error_ fails on local images with:
• NSOSStatusErrorDomain Code=-6662
• Failed to create CVPixelBuffer Width=..., Height=..., Format='420f'

Outside Codex sandbox (normal terminal process):

• The same image files succeed with Vision OCR and return text results.

Reproduction (minimal)

Run inside Codex sandboxed command execution:

import cv2
from dallas.analysis.ocr_engine import VisionOCRBackend

img = cv2.imread("/tmp/vision_live_test.png")  # or any local image
VisionOCRBackend().read_frame(img)

Actual result in sandbox:

• Raises RuntimeError("Vision OCR failed: Error Domain=NSOSStatusErrorDomain Code=-6662 ... Failed to create CVPixelBuffer ...")

Run the same command outside Codex sandbox (normal Terminal, same venv):

• OCR succeeds and returns text.

Representative failing images

Both fail in Codex sandbox, both succeed unsandboxed:

• Local screenshot file captured from ADB and saved to disk:
• /tmp/vision_live_test.png
• Extracted video frame (user_actions artifact):
• /Users/admin/conductor/workspaces/macos-adb-coplay1/dallas/data/sessions/e4f16847/artifacts/user_actions/v1/504d6f154a03/000001_before.jpg

What was tested (and did not fix it)

These still failed inside the sandbox:

• VNImageRequestHandler.initWithCGImage_options_
• VNImageRequestHandler.initWithData_options_ (PNG/JPG bytes)
• cv2.imread vs cv2.imdecode
• JPG -> PNG transcode
• Crop/resize/pad/normalize dimensions
• Explicit image-orientation init variants
• Keeping CGImage backing bytes/provider alive longer

Important diagnostic finding

The failure is not primarily caused by extracted image format/encoding.

It is environment-specific:

• Sandboxed Codex Python process: fails
• Unsandboxed terminal Python process: works

This strongly suggests a sandbox/CoreVideo/Vision runtime interaction issue (CVPixelBuffer allocation path).

Exact error seen

Example:

Error Domain=NSOSStatusErrorDomain Code=-6662 "Failed to create CVPixelBuffer Width = 1224, Height = 2712, Format = '420f'"

Impact

• Prevents reliable Vision OCR on local/offline images inside Codex tool-runner sandbox
• Breaks/complicates offline evaluation workflows that use Vision (unless run unsandboxed)
• Forces use of slower OCR backends or external terminal execution for benchmarking

Workarounds

1. Run Vision OCR workloads from a normal terminal (unsandboxed) process

• This works reliably in testing.

1. In some cases, a live Vision OCR “warm-up” in the same process can help, but this is not a root fix and is inconsistent.

Why this matters

Vision OCR is much faster than alternatives (e.g., EasyOCR), so inability to run it inside the Codex sandbox materially slows iteration and benchmarking.

Optional follow-up data (available on request)

• Exact commands used in both environments
• Minimal standalone PyObjC repro script (without project dependencies)
• Sample images that fail in sandbox / succeed unsandboxed