v7.86.1

Pairs with engine-service-v0.1.164 (REQUIRED_ENGINE_VERSION unchanged from 7.86.0), already deployed; no engine changesets. Fixes from the 7.86.0 post-release shakeout on macOS, Linux and Windows, and corrections to the 7.86.0 entries.

Fixed

• nx doctor now catches two OpenCV builds in one install, and a cv2 that cannot load (nexus-11x9o). opencv-python and opencv-python-headless both write site-packages/cv2/. The release's uv overrides keep only the headless one, but uv reads overrides from the command line, never from an installed wheel, so any install that ignores them (a bare uv tool install, pip, pipx) can land both. On a Linux box without libGL.so.1 the non-headless build then wins the directory, import cv2 fails, and every PDF fails with it: the MinerU server answered 409 and the per-page fallback exited 1, while nx doctor stayed green. The default PDF support row now reads the installed distributions (it never imports cv2) and goes red on Linux, a warning elsewhere, with nx self install --extras pdf as the repair. --check-mineru imports cv2 in a child process with a 60 s timeout, goes red with the cause and the same repair, and skips the real-parse probe that would die on the same import. The per-page MinerU worker's stderr was discarded; mineru_subprocess_failed now carries its last 2 KB as stderr_tail, credentials redacted. install.sh/ps1, setup, nx self install, the on-demand PDF install and the .mcpb already applied the overrides. The published-artifact run of tests/e2e/fresh-install-mvv.sh now applies the release's overrides and constraints too, and fails if the tool env holds the non-headless build.
• On native Windows, nx upgrade no longer leaves the local storage service stopped (nexus-9pc2f). Found in the 7.86.0 shakeout on a Windows guest. When an upgrade or an engine-pin bump restarted the service, it ran nx daemon service start inside a Windows job object that was closed as soon as the command returned, and closing the job killed the new supervisor and its engine with no log line. nx upgrade still exited 0, and the next command found no service (connection refused on the old port) until the stale lease expired. This hit local mode on native Windows, from 7.64.0, when the upgrade cycled the service and the logon task was not installed; Linux, macOS, cloud mode, and Windows installs with the logon task were not affected. The three restart sites (nx upgrade, the engine convergence pass, the autostart-unit reinstall) and the MinerU restart now start their child outside that job, and the supervisor asks Windows to break away from any job it is spawned into, retrying inside it when the job refuses. If you are already in this state after an upgrade, run nx daemon service start; nothing else needs repair.
• A plain nx self install records the version it installed, so the installer rebuild applies the lock to it (nexus-3yv0o). install_generation.sh and the Windows builder wrote the receipt version from --version, so a build with none recorded "", which never equals the running version, and the rebuild rung skipped that generation for good. A registry build now reads the version from the new venv's conexus-X.Y.Z.dist-info; an explicit --version still wins, and receipts already written with "" still read as before.
• A build that fails on the cu128 torch backend names cu126 (nexus-husxe). cu128 does not exist for this release's torch, so uv ends with a bare "unsatisfiable" and the remedy was only in the docs. On Linux, when NX_TORCH_BACKEND is cu128 (or auto and uv's output names cu128), the failure message says to set NX_TORCH_BACKEND=cu126, which covers CUDA 12.6 to 12.8 drivers.
• The Windows PDF carry-forward checks the Visual C++ runtime before it announces a download (nexus-p4vhj). On a machine without the runtime, nx upgrade printed "Carrying PDF support forward ... about 240 MB" and then "PDF support will not be installed by this build". The check now runs first, and such a machine sees only the second line. The carry builds slim on a runtime gap rather than refusing.
• nx store put drops a leading UTF-8 byte order mark (nexus-3ppub). Windows PowerShell 5.1 Set-Content -Encoding UTF8 writes one, and it started the stored chunk and the search output. A file is read as utf-8-sig, and a BOM at the start of stdin is removed when stdin decodes as UTF-8 (on Windows a piped stdin decodes with the console code page, so pass the file path instead).

Corrections to 7.86.0

The 7.86.0 entries below carry labels that the post-release shakeout (macOS, Linux, the artifacts) showed to be wrong. Nothing in the code changed for these; the words and figures did (nexus-q04tu).

• The install sizes are re-measured on 7.86.0 (macOS on hellmini, Linux on chas, 2026-10-25; Windows was not measured). The 7.85.0 figures were off. Local is about 0.8 GB down (1.0 GB on Linux) and 2.8 to 3.0 GB on disk; Cloud and CLI only about 0.5 GB down (0.6 GB on Linux) and 2.0 to 2.3 GB on disk. PDF support adds about 285 MB of download on macOS and 390 MB on Linux, and 1.0 GB on disk on macOS and 1.3 GB on Linux (the labels said 0.25 GB and 0.85 GB on macOS, 0.37 GB on Linux), so --slim saves that much. A slim CLI download is about 0.25 GB. The uv cache is about 2.2 GB on Linux and 1.9 GB on macOS; running install.sh on macOS adds about 0.84 GB more for its throwaway bootstrap environment, 2.8 GB in all, which the earlier figure left out. On Linux the cache and the install share files and together are about 2.3 GB. Corrected in the README, the install guides, /conexus:setup, the stand-in, the setup tool description, the first-use PDF notice and the Desktop extension's setting text.
• A bare uv tool install conexus does not fetch PDF support on the first PDF index. The README and the 7.86.0 entries said it does. The index stops with exit 69 and "Run: nx self install"; that command moves the tree onto the generation layout and brings PDF support with it. Only a slim generation install fetches it on first use.
• The shipped lock has 222 pins, not 219. The 7.86.0 entries for the PDF split and the .mcpb constraints floor quote 219; src/nexus/_install/constraints.txt has 222.
• The installer pages pass --extras pdf. The 7.86.0 entry on the PDF-stack skip line said web/install.ps1 and web/install.sh pass no extras and so build slim already. They pass --extras pdf unless --slim or -slim is given, and the comment in nx self install that said otherwise is fixed. The pages that are live today still pass none; the new ones publish after the client release that accepts --bootstrap --extras.
• The 46 advisories are raw pip-audit entries; 43 are distinct. The lock-refresh entry counted the entries.
• The weekly lock audit has not yet run from Actions. The 2026-10-24 run was by hand. The first scheduled run is Monday 2026-10-26 at 11:23 UTC.
• The .mcpb bundle's uv sync is pinned. The lock-pinning entry listed it under "Not covered". The bundle carries constraints.txt and bootstrap.py writes it into the bundle's pyproject.toml as constraint-dependencies before the sync, as a later 7.86.0 entry says.
• The disk rows in the 2k66t.4.9 entry are superseded. That entry quotes Local 2.4 to 3.1 GB, Cloud and CLI only 2.1 to 2.3 GB, and a slim saving of 0.8 GB on disk; they were derived, and the measured-sizes entry above it replaced them (now replaced again by the figures here).
• The macOS 14 floor comes from onnxruntime 1.31.0, not 1.24.2. The lock pins 1.31.0, whose macOS wheels for the supported Pythons (cp312 and cp313) are tagged macosx_14_0_arm64, so a macOS 13 Mac fails the resolve. The 7.86.0 entry named 1.24.2.
• The Windows PDF carry-forward builds slim; it does not refuse. The 2k66t.4.7 entry says the carry-forward and the self-install path "refuse with the same words before building". On a Windows machine missing msvcp140_atomic_wait.dll, nx upgrade's carry-forward builds a slim generation and prints the slim line, which is the policy the vyy65 entry describes.
• The "LLM key persistence (GUI spawn)" row of nx doctor is not always present. It appears, as a warning, only when the chosen backend is an API backend and its key is set in the shell environment but not stored with nx config set.