v7.79.0

Pairs with engine-service-v0.1.160 (REQUIRED_ENGINE_VERSION unchanged). The plugin starts its servers and hooks through a launcher and says plainly when the CLI is not installed (RDR-228 Phase 1). On Windows, nx programs no longer crash on a WMI query at import, and nx daemon service install-binary extracts the PostgreSQL bundle it installs. nx daemon service start starts an installed autostart unit through the OS manager.

Changed

• The conexus plugin starts its Nexus servers and hooks through a launcher, and a machine with the plugin and no CLI gets a true message in place of errors (RDR-228 Phase 1, nexus-sv2wx). conexus/.mcp.json and conexus/hooks/hooks.json no longer name nx-mcp, nx-mcp-catalog, nx-hook and nx-session-end-launcher directly; each entry runs uv tool run ... launch/nx_launch.py <program>. With no CLI the two servers connect as stand-ins that offer setup and setup_status (in this release setup installs nothing and answers with the install commands), one session-start message says Nexus is not installed, and every other hook entry writes one line. Before, that machine got six "Executable not found" hook errors, two failed servers and a message that an upgrade had been dispatched. What changes on a machine that has the CLI:
  • uv is now needed for the Nexus servers. They used to start without it; the plugin's other hooks and its thinking server already needed it. A CLI installed with pip or pipx on a machine with no uv loses both servers until uv is installed.
  • The plugin looks for the CLI in its install directory before PATH. An install made after the application started is found without a restart. On a machine with a generation and another nx earlier on PATH, the plugin's servers and hooks run the generation's programs; the /conexus:* commands still run the nx that PATH finds.
  • Each server has one resident uv parent process, and each server start and hook gains one uv launch (25 ms measured).
  • Claude Desktop picks this up only after the marketplace is removed and added again. Desktop keeps the plugin's earlier copy until then (RDR-228 Discovery 6).

Fixed

• On Windows, starting any nx program no longer queries WMI, which could crash it with no error (nexus-f9bgu.55). import nexus loads truststore, whose import called platform.system(); on Windows that queries WMI, and CPython 3.12's _wmi module crashes the process (0xC000070A) when the query times out, which happened under a session start's concurrent hook launches. Claude Code showed it as a conexus hook exiting 10, or 255 through the uv shim, with no stderr; it failed the Windows gate on every Home guest run and once on Pro. nx now answers platform.uname() from sys.getwindowsversion() and PROCESSOR_ARCHITECTURE before truststore loads, with the build number WMI reports (10.0.26200 on Windows 11 25H2, where Python's own fallback says 26100).
• nx daemon service install-binary now extracts the PostgreSQL bundle it installs (nexus-f9bgu.56). It placed the archive and stopped there, while the storage service finds PostgreSQL only in the extracted ~/.config/nexus/pg-bundle: a restart kept the old PostgreSQL, and on a box whose extracted tree was gone the stack could not start until nx init ran. The same archive already extracted is left alone; a different one is extracted beside the running tree and swapped in.
• On Windows, the logon task that starts the storage service now runs the current generation's interpreter (nexus-50l3e). It baked the interpreter of whatever ran nx, so nx init run through a legacy uv shim registered the legacy tree's pythonw, which a later session-start cleanup removes once nothing holds it. The task, its nx doctor row, the converge pass and nx self install's retarget now all name the generation current points at, falling back to the running interpreter when there is no layout or the generation has no python.exe. A task registered before this release keeps its interpreter until the next nx self install or autostart install re-registers it.
• The version-lockstep hook no longer says an upgrade was dispatched when there is nothing to upgrade or no nx to run (nexus-sv2wx.8, nexus-sv2wx.9). With no CLI it says and does nothing. Its detached action now finds nx the way the hook does, in the install directory and then on PATH.
• The session handoff on /clear and /resume finds a Nexus server that the plugin started through uv (nexus-sv2wx.8, RDR-228). The hook that hands the new session id to the running server looked only at direct children of the Claude process. The plugin's server entries are moving to uv tool run ... launch/nx_launch.py nx-mcp, and uv stays alive as the parent of what it runs, so the server becomes a grandchild and was not found: the server's session scratch would have stayed on the old session after /clear, with no error. The lookup now also looks through a child that is uv or a Python running the plugin's launcher, and through nothing else, so one session still cannot reach another session's server.
• On Linux and macOS, an autostart unit installed while ~/.local/bin is not on PATH now names the nx shim, not the running interpreter (nexus-wkkeq). With nx off PATH, the unit fell back to python -m nexus.cli with the interpreter of the current generation, which a later nx self install replaces and then deletes, leaving the unit pointing at a missing file. The shim follows the current generation. With no shim installed, the interpreter form is kept.
• nx daemon service start, nx init --service and the Windows upgrade restart now start an installed, enabled autostart unit through the OS manager (nexus-crwqm). With the unit installed and the service stopped, they used to spawn a detached supervisor itself, which left the unit inactive, so systemd or launchd never supervised or restarted the service. It now runs systemctl --user start, launchctl kickstart or schtasks /Run and waits for the endpoint the unit's supervisor publishes; that path never spawns a supervisor itself. A box with no unit, a unit installed for a different config dir (or one whose config dir cannot be read), a NEXUS_SERVICE_BIN or NEXUS_SERVICE_JAR set in the calling process (the unit's supervisor would not see it), a unit the manager does not report enabled, or a failing manager command keeps the detached spawn and prints one line saying why; that spawn can race a unit that is itself mid-start. A unit that does not become ready within 60 s is an error naming the unit's own log. A service that is already running is reported without asking the manager; --foreground is unchanged.
• Aspect extraction no longer waits 15 seconds per document for an MCP server it never starts. The extractor's claude -p child passed --strict-mcp-config but still loaded the user's settings, so it ran every SessionStart hook, and the conexus plugin's own connection wait then timed out at its full bound on each call. The child now passes --setting-sources "", as the operator dispatch already did. Measured on a one-line prompt on 2026-10-13: 19 s and 12.3k context tokens before, 2 s and 6.7k after. Auth supplied by an apiKeyHelper in a settings file is not seen by the child any more; environment and keychain auth are unaffected.
• The Claude Desktop bundle launcher and the hook scripts no longer take a uv.exe, git.exe or nx-hook.exe from the working directory through a PATH entry on Windows (nexus-f9bgu.38). Both carry their own copy of the PATH lookup, because neither can import nexus. The bundle launcher skipped neither a relative entry (PATH=tools returned tools\uv.exe) nor an entry that is the working directory; the hook copy skipped relative entries but not the working directory's own, and both tried uv.exe.cmd for a name that already ended in .exe. They now follow the same rules as nexus.util.nx_argv, and one test runs all four copies over the same cases. These two copies also no longer return a .cmd or .bat hit, which nx_argv already refused: a batch file runs through cmd.exe with quoting Python does not escape for it, so a uv or nx-hook that exists only as a batch file now counts as not found. The bundle launcher also no longer falls back to the bare name uv when it finds none on PATH: that name was spawned for uv sync, and CreateProcess searches the working directory first, so a planted uv.exe would have run. It now exits 127 with the launch step's message before spawning anything. All four copies also recognise a PATH entry that spells the working directory with . or .. parts (C:\proj\sub\..); an 8.3 short name is not recognised. The off-cwd rules ran on a Windows host on 2026-10-13 (tests/test_off_cwd_resolver_real_windows.py).