diff --git a/.github/workflows/nightly.yaml b/.github/workflows/nightly.yaml
index 81a2fff..15c8a9c 100644
--- a/.github/workflows/nightly.yaml
+++ b/.github/workflows/nightly.yaml
@@ -24,7 +24,6 @@ on:
     - cron: "0 6 * * *" # Every day at 06:00 UTC (00:00 CST)
 
 jobs:
-  # allow_macos_failure: see pull_request.yaml's comment on the same input.
   test_cmake_build:
     uses: NWChemEx/.github/.github/workflows/test_nwx_cmake_build.yaml@master
     with:
@@ -32,8 +31,8 @@ jobs:
       cmake_opts: "-DINTEGRATION_TESTING=ON"
       python_version: "3.12"
       extra_pip_packages: "nwchemex"
-      allow_macos_failure: "true"
 
+  # allow_macos_failure: see pull_request.yaml's comment on the same input.
   test_pip_build:
     uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master
     with:
diff --git a/.github/workflows/pull_request.yaml b/.github/workflows/pull_request.yaml
index 7a20d9a..d8885ea 100644
--- a/.github/workflows/pull_request.yaml
+++ b/.github/workflows/pull_request.yaml
@@ -29,10 +29,6 @@ jobs:
     with:
       doc_target: "scf_cxx_api"
 
-  # allow_macos_failure: SCF has a known, tracked, macOS-only segfault (see
-  # scf-macos-pybind11-segfault.md). macOS still runs and reports its real
-  # result -- visible signal for the investigation -- but doesn't block this
-  # workflow or PR merge readiness. Drop once the segfault is fixed.
   test_cmake_build:
     uses: NWChemEx/.github/.github/workflows/test_nwx_cmake_build.yaml@master
     with:
@@ -40,8 +36,17 @@ jobs:
       cmake_opts: "-DINTEGRATION_TESTING=ON"
       python_version: "3.12"
       extra_pip_packages: "nwchemex"
-      allow_macos_failure: "true"
 
+  # allow_macos_failure: test_pip_build's macOS gcc-14 leg has a separate,
+  # pre-existing, unrelated failure -- meson can't detect Homebrew gcc-14's
+  # linker on macOS ("Unable to detect linker for compiler `gcc-14
+  # -Wl,--version`": Homebrew's GCC uses Apple's native ld64 under the hood,
+  # not GNU ld, and meson's linker probe assumes GNU-compatible --version
+  # support for any gcc-family compiler) when building numpy from source
+  # (no cp314-compatible prebuilt wheel; see scf-macos-pybind11-segfault.md's
+  # original failure table -- this leg failed deterministically even before
+  # that investigation). Not the pybind11 segfault, not fixed by
+  # NWChemEx/.github#189. Drop once this is separately investigated/fixed.
   test_pip_build:
     uses: NWChemEx/.github/.github/workflows/test_nwx_pip_build.yaml@master
     with:
diff --git a/pyproject.toml b/pyproject.toml
index a218a9d..6235234 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -19,13 +19,22 @@ requires = [
     # gau2grid (fetched transitively via GauXC) invokes a Python codegen
     # script at CMake configure/build time that imports numpy -- needed in
     # the isolated build env even though scikit-build-core's build-system
-    # deps are otherwise C++-only. Capped below 2: newer numpy releases only
-    # ship manylinux2014 wheels for a GCC >= 10.3 build, and manylinux2014's
-    # own GCC 10.2.1 can't build numpy from source either, so an unpinned
-    # requirement falls back to a source build that fails outright. This
-    # cap only affects the isolated build env, not the runtime numpy version
-    # a user ends up with (see requirements.txt for that).
-    "numpy<2",
+    # deps are otherwise C++-only. Capped below 2 on Linux only: newer numpy
+    # releases only ship manylinux2014 wheels for a GCC >= 10.3 build, and
+    # manylinux2014's own GCC 10.2.1 can't build numpy from source either, so
+    # an unpinned requirement falls back to a source build that fails
+    # outright there. This cap only affects the isolated build env, not the
+    # runtime numpy version a user ends up with (see requirements.txt for
+    # that). macOS has no such manylinux/GCC-ABI constraint -- its wheel tags
+    # are keyed on the deployment target, not the build GCC -- so leaving it
+    # unpinned there lets pip resolve a real numpy>=2 wheel for whatever
+    # Python is active (e.g. cp314), instead of falling back to a numpy<2
+    # source build that has no cp314 wheel and fails distinctly: Homebrew's
+    # gcc-14 has no bundled linker, so it shells out to Apple's system ld,
+    # and meson's linker-detection probe (`gcc-14 -Wl,--version`) fails
+    # against it ("ld: unknown options: --version") on current macOS/Xcode.
+    "numpy<2 ; sys_platform == 'linux'",
+    "numpy ; sys_platform != 'linux'",
 ]
 build-backend = "scikit_build_core.build"