›_ Codex Issues
Codex Issues / #12616

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

Resolved 💬 5 comments Opened Feb 23, 2026 by piter239 Closed Feb 26, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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

View original on GitHub ↗

5 Comments

etraut-openai contributor · 6 months ago

Thanks for the bug report. This is likely not a bug in Codex but rather a limitation due to some resource that this app needs to access — one that would be unsafe to allow access in general within the sandbox.

Since this is so specific, it's not likely that we'll prioritize looking at it any time soon. You or other members of the Codex community are welcome to investigate further and see if you can determine what resource the app is accessing (perhaps a device or a file in the file system). And based on that information, you can then decide whether: 1) this is a problem that the maintainer of this app can address, 2) there's a way to configure the Codex sandbox to allow access to that resource, or 3) we need to add additional controls for Codex sandbox configuration.

piter239 · 6 months ago

Follow-up: I reduced this to a standalone repro script (no project imports) and confirmed the issue with the same image + same Python/venv.

Key result:

  • sandboxed Codex command path (/bin/zsh -lc '.venv/bin/python3 ...'): fails with NSOSStatusErrorDomain Code=-6662 for both VNImageRequestHandler.initWithData_options_ and initWithCGImage_options_
  • unsandboxed run (same command with sandbox escalation / normal terminal): succeeds and returns OCR text for both handler paths

I also verified the minimal script succeeds on a small generated PNG inside the sandbox, so the failure is not "Vision always broken" in sandbox. It appears tied to the CoreVideo/CVPixelBuffer path for larger real-world images (e.g. 1224x2712 extracted frame).

Standalone repro script (local):

  • repro-artifacts/codex-vision-sandbox/vision_ocr_sandbox_repro.py

Representative image used:

  • local JPEG extracted frame (1224x2712) with text

Representative sandbox failure output (truncated):

  • Failed to create CVPixelBuffer Width = 1224, Height = 2712, Format = '420f'

Representative unsandboxed success output:

  • both handler modes return ok: true and OCR text rows

If useful, I can paste a fully self-contained script snippet directly into the issue body/comment (currently I kept it local while validating the behavior).

miraclebakelaser contributor · 6 months ago

I've encountered this issue running ffmpeg transcodes within Codex using hevc_videotoolbox. Seeing your issue, I bet it has to do with how sandboxing interacts with things that use Apple's frameworks.

@piter239 you can fix this by asking Codex to raise the failing command for your approval. It will ask for your approval to run the command. After you approve within Codex, the command will run successfully. If you run into this frequently, put the instruction to raise this subset of failures into your AGENTS.md. Setting permissions to "Full Access" also does the trick.

@etraut-openai this is not a harness issue. It should be forwarded to your model tuning team under the category of "model needs to be better at elevating command for approval". It's tough b/c the errors returned by the scripts are vague and dont remotely hint at permissions issues. In my case, it's Error: cannot create compression session: -12903. @piter239's, it's Failed to create CVPixelBuffer ... Format = '420f'

I sent feedback on a couple threads to demonstrate the behavior.
good result: 019c9089-f13f-7282-9528-37623245f0c0
bad result: 019c9086-f967-7743-8e62-47ab2d5e97f4

piter239 · 6 months ago

@miraclebakelaser thanks for the hint! The error message is indeed not helpful at all.

Running the code in question outside of sandbox was exactly how we - together with Codex - worked around this issue at the end, before submitting this here.

"Full Access" does not sound like a reliable solution to me, it would be THE wrong step toward some really interesting problems I would rather not have in the nearest future.

@etraut-openai Eric, thanks for the feedback from the vendor. My reason to ask Codex to submit detailed bug-report was to give a hint for other users that this is not a problem with their ML/OCR configuration but a specific sandbox issue.

In my case, Codex needed about 20 minutes of intensive experiments before surfacing the idea this error depends on sandbox. After this insight the solution was clear.

I will remember to post the work-around together with the description of the issue in the future; or rather - instruct the agent to do so.

etraut-openai contributor · 6 months ago

Thanks, I'm going to close this issue because I don't think there's anything actionable for the Codex harness.