[Feature]: detect Desktop supervision on Windows so status, doctor and lifecycle commands defer to the Desktop runtime #6853

Area

Platform (Windows / macOS / Linux)

What are you trying to accomplish?

Run an npm, Homebrew or bun link ocx next to OpenCodex Desktop on Windows and get the same Desktop-aware behaviour macOS and Linux got in #6802 and #6809: ocx status, doctor and resolve name the Desktop as the runtime's supervisor and stop recommending ocx service ... repairs, and ocx service install, start, stop and update refuse to compete with (or warn about) the runtime the Desktop owns.

What prevents this today?

inspectDesktopSupervision() returns { kind: "unsupported" } for anything but darwin and linux (src/service/desktop-supervision.mjs:74-75), so on Windows every consumer behaves as if no Desktop were running.

Observed on a Windows 11 (build 26200) machine with OpenCodex Desktop 2.77.0 (per-machine MSI, C:\Program Files\OpenCodex) running and its sidecar serving 127.0.0.1:10100, using a CLI built from dev (d17a9f2239, 2.82.0):

• ocx resolve --json → "supervisor": {"kind":"unsupported"}; inspectDesktopSupervision() → {"kind":"unsupported"}.
• At the same moment Win32_Process shows the sidecar (ocx.exe, PID 33476) is a child of opencodex-desktop.exe (PID 22680), both images under C:\Program Files\OpenCodex\, both in session 1. The facts needed for a proof are there.
• ocx status tells the user to restart the proxy with ocx service restart (version skew 2.82.0 vs 2.77.0), reports Restart safety: AT RISK and run 'ocx service repair'; ocx doctor recommends ocx service repair and ocx service restart — exactly the advice fix(cli): treat a Desktop-supervised runtime as the authority in status, doctor and resolve #6802 suppresses on macOS and Linux.
• By code (not run against the live install): ocx stop takes the ordinary stop path without the Desktop notice (src/cli/desktop-runtime-guidance.ts:27), ocx service install passes src/service/desktop-command-guard.ts:24 and may clear existing managers and the tracked listener, and ocx update gets no Desktop veto from src/update/runtime-ownership.mjs:45.

The package launcher's PATH-only behaviour on Windows (src/lib/desktop-cli-handoff.mjs:19, windows-path-only) is a separate, deliberate decision and is not what this issue asks to change.

What should OpenCodex do?

Teach inspectDesktopSupervision() to prove Desktop supervision on Windows with the same standard as the Linux /proc proof: the runtime PID from ocx.pid and runtime-port.json agree; the runtime process's parent PID is a live opencodex-desktop.exe; both image paths (QueryFullProcessImageNameW) resolve into the same install directory and the runtime image equals the Desktop's sibling ocx.exe; parent and child share a session; the parent's creation time precedes the child's (guards PID reuse); and two snapshots agree. Anything inconclusive stays unknown, never desktop. With that, the existing #6802 and #6809 consumers apply on Windows without further changes.

Example usage or interface

> ocx resolve --json
{ ..., "supervisor": { "kind": "desktop", "pid": 22680, "app": "C:\\Program Files\\OpenCodex\\opencodex-desktop.exe" } }
> ocx service install
OpenCodex Desktop supervises the running proxy (pid 22680); refusing to install a competing background service.

Alternatives or workarounds

Today a Windows user has to know not to run ocx service ..., stop or update from a package install while the Desktop runs. A WMI query (Win32_Process) gives the same facts but costs a PowerShell or COM round trip on every status; a toolhelp snapshot plus OpenProcess/QueryFullProcessImageNameW/GetProcessTimes is cheaper but needs a native helper or FFI from the Bun runtime.

Additional context

Related follow-up found in the same probe: when the package launcher cannot run Bun, its failure text names the Desktop CLI only on macOS (findDesktopCli(), src/lib/bun-path-runtime.mjs:79-82). On Windows it could name the Desktop's InstallLocation ocx.exe; on Linux it could name /usr/bin/ocx only after proving it is the deb's binary rather than an npm --prefix /usr symlink. Observed texts: Windows the \bun` dependency is not installed., Linux Bun binary missing after install attempt.`

Found while probing the desktop-owned CLI path work (#6802, #6807, #6809, #6812, #6816, #6818) on real Linux and Windows hosts; the probe record is devlog/_plan/261010_cli_path_crossos_probe/029_wp3_outcome.md (rows W7/W8).

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.