3.7.4: preserve Codex plugin choices across TOML syntax

NexusWindows for Codex now reads plugin choices with one bundled TOML parser across npm setup and source installation. Valid alternate TOML syntax (literal keys, spaces around dotted keys, inline tables and escaped keys) preserves disabled plugins and plugins from another catalogue. Comments and multiline text cannot create false plugin declarations.

Existing custom MCP commands remain unchanged. Existing plugins do not start a second MCP runtime or build another native helper, and disabled installations receive no fallback guide. An owned older standalone guide is archived. Invalid TOML and an older CLI stop installation before changes.

Validation: JavaScript regression tests, 20 private installation tests, source clone installation and repeated CheckOnly runs in isolated profiles, native helper build and indicator rendering, publication preflight with secret/history/workflow checks. Runtime API fields are unchanged.

3.7.3: public guides for every user

The bundled public guide addresses every user and reserves question cards for real questions requiring an answer. Progress uses ordinary commentary. Existing API field names remain compatible. Publication audit, 301 Node tests, native helper build and isolated installation checks passed.

3.7.2: the Windows guide ships with every Codex installation

3.7.2 packages the Codex guide, references and portable entry in the plugin and npm distribution. Direct setup reuses enabled plugins, preserves disabled plugins and archives the earlier standalone guide. Validated with 301 Node tests, native helper build, plugin installation in an isolated profile and npm package contents.

3.7.1: launch with arguments, quotes included

Fixed

• launch now starts a program with its arguments instead of refusing it: a Windows command line with or without
  quotes ("C:\My Apps\app.exe" "C:\x\note.txt", app.exe C:\x\note.txt) or the new optional args field.
  Existing paths with spaces are never split, and opening is still verified. Arguments are accepted only for a program,
  and a Chromium/Electron application (Chrome and Edge included) never receives a switch from the model, as split by
  CommandLineToArgvW.

3.7.0: interaction for one call, modal dialogs followed, background double click

Added

• act accepts interaction: true: the foreground is held for the duration of that single call (30 s at most) and
  given back even after a refusal. Before any input, the observation must still be current, and the first target (or,
  for a first key without selector, the focused element) must keep the same identity and ancestry after activation;
  otherwise nothing is sent. Replaces holding beginInteraction from the Node library across calls.

Fixed

• A target inside the modal dialog of a disabled window (Paint "Save as", which UI Automation lists under its owner)
  now acts on that dialog, geometry included, instead of being refused; a dialog that appears while an action is read
  back is followed before the result.
• Explorer context menu: an item exposed twice is read once, and its ancestry is checked against the full reading (no
  more false "Control ancestry changed").
• Expand refused by the application: the state is read back ("no effect", never "unknown"); one Invoke fallback at
  most, with the emergency stop checked right before it; only attested UI Automation refusals count as refusals, any
  other error stays unknown and nothing is sent again.
• launch: proof "folder" when a new Explorer window shows the requested folder; a Store app launched by its
  identifier is attributed by the process of its content.
• Double click on a list or tree item goes through UI Automation Invoke in the background; renaming in Explorer is
  documented in the background (F2, value, Enter), without the real keyboard.

3.6.2 — Look-alike letters restored in the guardrails

Fixed

• Guardrails: the lowercase look-alikes в, к, м, н, т (Cyrillic) and β, η (Greek), dropped by mistake from the
  detection table in the previous release, are back ("Coмmander", "Posтer" are recognised again); a test checks every
  letter of both tables and that the set can no longer shrink.

3.6.1 — Tk buttons, guardrails, signed releases

Fixed

• Click at a point on a Tk button (Button, Checkbutton, Radiobutton), for instance on its text read by OCR: the button
  is invoked by the message Tk itself handles (BN_CLICKED posted to the button), command and variable included, in the
  background; the simulated mouse did not reach it. Checked on a real Tk window: one command per click, a check box
  on then off.
• Guardrails: an invisible format character (zero-width space, soft hyphen, direction mark) or a Cyrillic or Greek
  look-alike letter no longer lets a word that needs confirmation slip through ("Env\u200boyer" displays as
  "Envoyer"). Look-alikes count for detection only.

Security

• CodeQL code scanning (JavaScript, C#, workflows); the npm tarball of each release attached to its GitHub release with
  a Sigstore attestation and SHA256SUMS.txt (gh attestation verify <file> --repo pironjulien/NexusWindows-Codex);
  SECURITY.md states response times and coordinated disclosure; npm is no longer installed by hand in the publish
  workflow (Node 24 ships the npm that trusted publishing needs).

3.6.0 — OCR and Windows.Graphics.Capture

Added

• Text read by OCR when the UI Automation tree is too thin (fewer than 6 elements: Tk, canvas, game): Windows.Media.Ocr
  in the native helper, on the full-resolution pixels of the capture just made (one capture is made for it in mode
  text). look returns ocr.lines with each line's text, bounds and center point in pixels of that image and its
  screenshotId, ready for a click at that point; 18 to 34 ms per window.
• Guardrails on such a window: before a gesture at a point, a key or a selector click, the text is read again on a
  fresh capture and every line is judged like a button label (confirmation words need confirm, outward words also
  the exact-action accord, which binds the whole text read and is voided when the canvas text changes). A fresh read
  that is impossible refuses the gesture before any input; only a system without OCR behaves as before.
• Windows.Graphics.Capture when PrintWindow fails or returns a uniform image: the window's own DWM surface, no cursor,
  no yellow border where Windows allows it, works covered; never a screen copy. One capture item is kept per window
  (Windows keeps about one kernel handle per CreateForWindow call): no handle lost over 40 captures, 16 to 20 ms each.
• WinRT and Direct3D 11 called as raw COM from the .NET 10 helper (interface ids and slots checked against the system
  metadata): no 25 MB WinRT projection, no package. Helper self-tests --ocr-selftest and --wgc-selftest (its own
  window at the bottom of the z-order, never activated).

Changed

• A blank native capture of a native-only window is reported as "image unavailable", never replaced by a screen copy.

3.5.0: Tk mouse wheel in the background

Added

• Mouse wheel on a covered Tk window without the foreground or the real mouse (until now no edition had a background
  technique). Tk sends the wheel to the window visible at the point of the message, so on a covered window it was
  lost. With no native scroll bar beside the control, a Tk window that is ENTIRELY covered is moved beyond the virtual
  desktop (no activation, no z-order change), the wheel is posted to the same control there (found before the move),
  and the window comes back to its place, read back to the pixel. Coverage is exact: the target frame minus the frame
  of each window above it; only windows proven opaque count (not layered, transparent, without redirection bitmap or
  shaped by SetWindowRgn), with rounded DWM corners left out at their monitor's scale; a one-pixel visible strip is
  enough to refuse. Also refused, nothing sent: maximized or minimized window, another control under the point once
  moved, window brought forward meanwhile. A window that cannot be put back fails the action for good (no fallback,
  never turned into a success). Common bench: Tk wheel 3/3 on a covered window, no foreground taken.

3.4.0: MCP 2026-07-28, .NET 10

Added

• MCP protocol 2026-07-28 (stateless MCP), alongside 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05: server/discover
  advertises the supported versions, capabilities and instructions; a request carrying
  io.modelcontextprotocol/protocolVersion in _meta is served without an initialize handshake; its results carry
  resultType: "complete" and the server identity (io.modelcontextprotocol/serverInfo); tools/list carries
  ttlMs: 0 and cacheScope: "private". An unsupported version gets error -32022 with the supported versions.
  initialize and ping stay for earlier clients, which see no change. Checked with the official MCP Python SDK
  2.3.0 client in its three modes (automatic discovery, legacy handshake, pinned 2026-07-28).
• Explicit observation id: look (and an act that refreshes) returns observation obs-…; act takes it as
  observation and refuses it, before any input, once another look replaced it. With protocol 2026-07-28 the id is
  required, look and window need a named window, a region names its image (screenshotId, refused once a newer
  image of the window replaced it) and images are always attached: no window, observation or image is carried over
  implicitly from another call, so two conversations sharing the server never act on each other's window. Earlier clients may still
  omit both.

Fixed

• Protocol 2026-07-28: a request without io.modelcontextprotocol/clientCapabilities in _meta is rejected with
  -32602 before reaching any tool; a server/discover sent as a notification (no id) gets no reply.
• Native image ids are native-<session>-N instead of native-N: after a server restart, an old image named by a
  caller is no longer taken for a new image with the same number.

Changed

• Native helper and test fixture on .NET 10 (LTS), instead of .NET 8, which leaves support on November 10, 2026.
  Building from source needs the .NET 10 SDK; the npm package still ships a self-contained helper (no .NET install).