macOS sandbox blocks hw.optional.neon sysctl, causing Qt arm64 builds to fail with “Incompatible processor” inside Codex

I can reproduce what looks like the same root issue through Julia plotting on Apple Silicon macOS.

Environment:

• Codex CLI 0.118.0
• Apple Silicon macOS
• Julia 1.12.2 from MacPorts (/opt/local/bin/julia)
• Plots 1.41.3
• GR 0.73.19
• GR_jll 0.73.19+1
• Qt6Base_jll 6.8.2+2

So Julia itself is MacPorts-managed, but the Qt runtime used by the plotting stack is Julia’s Qt6Base_jll, not MacPorts Qt.

In a restricted Codex sandbox session, a simple Julia plot that writes a PNG aborts with:

Incompatible processor. This Qt build requires the following features: neon

Minimal reproduction:

julia -e 'using Plots; x = range(0, 2pi; length=300); y = sin.(x); p = plot(x, y); savefig(p, "/tmp/test.png")'

In my case:

• simple Julia computation works
• Julia package access works
• the plotting failure appears when Plots/GR triggers the Qt helper path
• the same plotting script succeeds after restarting Codex in a full-access session

So this seems consistent with the sandbox affecting Qt runtime feature detection or the runtime environment seen by the GR Qt helper, rather than the machine actually lacking NEON.

If you want to mention the related issues too, add one final line:

This seems closely related to #7099, and possibly more broadly to #11210, in the sense that the macOS sandbox appears to interfere with runtime CPU/hardware detection.

If you're able to upgrade to Qt 6.10 or Qt 6.11 the problem goes away.

On Thu, Apr 9, 2026 at 3:13 PM YAO, Yuki @.***> wrote:

yaoyuki left a comment (openai/codex#7099) <https://github.com/openai/codex/issues/7099#issuecomment-4217967815> I can reproduce what looks like the same root issue through Julia plotting on Apple Silicon macOS. Environment: - Codex CLI 0.118.0 - Apple Silicon macOS - Julia 1.12.2 from MacPorts (/opt/local/bin/julia) - Plots 1.41.3 - GR 0.73.19 - GR_jll 0.73.19+1 - Qt6Base_jll 6.8.2+2 So Julia itself is MacPorts-managed, but the Qt runtime used by the plotting stack is Julia’s Qt6Base_jll, not MacPorts Qt. In a restricted Codex sandbox session, a simple Julia plot that writes a PNG aborts with: Incompatible processor. This Qt build requires the following features: neon Minimal reproduction: julia -e 'using Plots; x = range(0, 2pi; length=300); y = sin.(x); p = plot(x, y); savefig(p, "/tmp/test.png")' In my case: - simple Julia computation works - Julia package access works - the plotting failure appears when Plots/GR triggers the Qt helper path - the same plotting script succeeds after restarting Codex in a full-access session So this seems consistent with the sandbox affecting Qt runtime feature detection or the runtime environment seen by the GR Qt helper, rather than the machine actually lacking NEON. If you want to mention the related issues too, add one final line: This seems closely related to #7099 <https://github.com/openai/codex/issues/7099>, and possibly more broadly to #11210 <https://github.com/openai/codex/issues/11210>, in the sense that the macOS sandbox appears to interfere with runtime CPU/hardware detection. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/7099#issuecomment-4217967815>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKKDAZLLME6COVHC4WHPND4VAOBBAVCNFSM6AAAAACM2JE7WSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMJXHE3DOOBRGU> . You are receiving this because you authored the thread.Message ID: @.***>

We reproduced this exact failure in the Codex macOS app environment on Apple Silicon while working on a Python/PyQt6 application.

With the previously used runtime (PyQt6==6.7.1, resolving PyQt6-Qt6==6.7.3), the smallest reproduction was:

uv run python -c 'from PyQt6 import QtCore; print(QtCore.qVersion())'

It aborts before Python can handle an exception:

Incompatible processor. This Qt build requires the following features:
    neon

The failure occurs during native QtCore initialization, not in application code. We also tested QT_NO_CPU_FEATURE=neon and QT_NO_CPU_FEATURES=neon; neither changed the result. A newer PyQt6/Qt6 pair worked in the same isolated environment, but we are treating that as a workaround rather than proof that an application-wide upgrade is safe.

This reproduced behavior is consistent with the sandbox blocking Qt’s hw.optional.neon hardware-feature probe. Apple Silicon should support NEON, so the message appears to reflect the sandboxed probe result rather than a missing CPU capability. The project’s existing PDF path also works by using PyMuPDF to rasterize PDF pages and ordinary Qt image widgets; it does not load QtPdf/QPdfView.

For reference, the affected application is AutoClean EEG, and the native Qt failure is reproducible before importing MNE, pandas, or the application’s PDF code.