nexus-windows-codex
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEXUS_GARDE_FOUS | No | Path to an alternative guardrails policy file. If missing or invalid, every action is refused. | |
| NEXUS_JOURNAL_HOME | No | Overrides the directory where the short monthly JSONL journal is written. | |
| NEXUS_WINDOWS_INDICATOR | No | Set to 0 to disable the on-screen busy indicator shown while actions run. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| windowsA | Application windows on the desktop (id, app, title, pid), like the taskbar, plus open dialogs (a file "Open" box…) with dialogOf: the window that owns them; look at a dialog by its id or title. Password managers are never listed. filter: part of a title or app. |
| lookA | See a window in the background, without bringing it forward: UI Automation tree (roles, names, ids, values, states) and, with mode image or both, a native capture that works even when the window is covered (WebP, at most 1568 px; unchanged since the last image sent: not attached again, mode image always attaches it). Selects that window for act; an observation serves one act and expires after 60 s. |
| actA | Steps on the window of the last look, in the background first (Win32 messages, UI Automation, DevTools for Chromium), the real mouse/keyboard only as a fallback under the shared foreground token. One step, or up to 32 each with its own expect; stops at the first step not verified. Per step: ✓ verified, = already done, ~ unknown (never replayed: look again), ✗ failed or refused. |
| launchA | Open an application (name, absolute path or Store app id), a folder or a document (absolute path) or a Settings page (ms-settings:...) and give the foreground back to the user. Returns the windows attributed to this launch, each with its proof: "process" (the process the shell returned) or "application" (the requested application, started after the request: another instance started at the same moment could be taken for it); other new windows come back as candidates (outcome unknown). Look at one before acting. |
| windowB | close: close the window (one close message, read back; a "save?" prompt is reported, never answered). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
The core actions are mostly distinguishable: windows lists windows, look inspects one, act operates on the last looked window, and launch opens apps. However, the near-identical names windows and window are confusing, especially since window only closes a window rather than managing one generically. look also overlaps conceptually with windows because both are observation tools, though at different levels of detail.
The set mixes plural/singular nouns (windows, window) with bare verbs (act, launch, look), and act is especially vague on its own. There is no predictable verb_noun or resource_action pattern. The names are readable only because of their descriptions, not because of a consistent convention.
Five tools is well-scoped for a desktop automation server: observe windows, inspect a window, act, launch, and close. Each tool appears to have a distinct role in the workflow. The count is neither thin nor bloated.
The surface covers the core loop of listing windows, looking at one, acting on it, launching apps, and closing windows. However, window management is notably thin: close is the only explicit window operation, with no obvious focus, move, resize, minimize, or maximize operations. Agents can likely work around some gaps through act, but the window lifecycle is not fully represented.