Complete reference

How Nyx AI works.

The detailed reference for app workflows and edge cases. New here? Start with the short Getting started guide, then return here when you need specifics.

Getting started Feature list Security model Get Nyx AI

Before you rely on it

Nyx AI is beta software, and AI output can be wrong, incomplete or insecure. Review, test and verify everything before you run it, deploy it or rely on it. For ordinary risky model-issued actions, the approval prompts, per-mode rules and native dialogs form the user-control safeguard. Enabled Auto-verify uses its documented bounded prompt-free path; the guided Build pipeline has no entry point in the current free interface. Outside a Sandbox isolation level, one native Allow for repository-controlled execution covers later commands in that category in the same workspace for the rest of the app session, including later model-issued commands; high- and critical-risk commands keep their own confirmation. The sandbox alone is not a complete safeguard. Nyx AI is a development tool, not a substitute for professional advice, and it is provided under the licence and terms on an “as is” basis, without affecting your statutory rights. You are responsible for your own code, data and backups.

The big picture

Nyx AI is a local-first AI coding workspace. Its agent, your documents, your code, your prompts, your chat history, your API keys and the search index all live on your own machine, and Nyx AI sends us no usage tracking, analytics, or crash reports. For Microsoft Store installs, Microsoft separately gives us mostly aggregate store reports, and their Health data can sometimes include event-level detail such as an individual stack trace or crash-dump file, collected by Microsoft under Microsoft’s terms rather than sent by the app. Data leaves your computer through network features you configure, trigger, or leave switched on. The obvious one is choosing a cloud model. The one to know about is the automatic update check: it is on by default (you can turn it off) and tells our update host your app version and IP. Features you have already enabled can also call out on their own, without asking each time: automatic chat titles and background helper calls, semantic-search embeddings, API-key checks, first-use downloads, language-server prewarming in a trusted workspace, MCP servers connecting or reconnecting, and scheduled tasks. The threat model summarises the main network paths the product manages. Worth knowing: software you install and commands you allow can add their own traffic on top.

Models & keys

You bring your own model — and the runtime that serves it. Nyx AI ships no AI models and no inference engine of its own. On first run you can configure a provider or choose Set this up later. When you configure one, it can be a local model through Ollama, which needs no API key. Ollama is a separate free program, not part of Nyx AI: install it, leave it running, and pull at least one model into it (ollama pull) before Nyx AI can use it. Nyx AI links you to the download when it doesn’t find one, and tells you plainly when Ollama is running but has no model installed yet. Leaving the picker on Auto, where it starts, does not mean local-first. Fast and synthesis helpers prefer a suitable loopback model and fall back to an eligible cloud route only if none is available, but the heavier coding, reasoning and planning roles are cloud-first by default. Some entries in the picker carry a “⚠ licence terms”marker. It is a prompt to check that model’s terms with your provider, not an acceptance step inside Nyx AI — and its absence is not a clean bill: models without the marker still have licence terms of their own. Prefer local models for all auto-routed roles (cloud fallback) extends the helpers’ preference to those roles too, and only to a local model that actually declares the role it is being asked for; as its own label says, it is a preference, not a hard cloud block. Separately, if a local model cannot read an image Nyx AI hands it to whichever vision-capable model its provider list offers first, which can be an eligible cloud route rather than a local vision model you have installed, after an on-screen notice. Keep local-model images on this device, off by default, is what blocks that cloud handoff. Or choose a cloud provider (OpenAI, Anthropic, direct Ollama Cloud, or a supported compatible endpoint). A compatible endpoint you point a provider slot at is discovered over /v1/models and then called on /v1/chat/completions (OpenAI-compatible) or /v1/messages (Anthropic-compatible); the stock provider hosts use built-in model lists instead. One practical limit follows from those paths: the endpoint has to expose them exactly, so Google Gemini’s native /v1beta/openai layout, which places them elsewhere, does not resolve through the OpenAI-compatible adapter. Direct routes use credentials you configure. Ollama :cloud and -cloud models can instead use a locally signed-in Ollama daemon without a key stored in Nyx AI, but still run off-device. A key is stored with Electron safeStorage backed by Windows DPAPI when it is genuinely available, and decrypted in memory to make your calls. DPAPI is tied to your Windows account rather than exclusively to Nyx AI, so same-user code running under Standard may be able to ask Windows to decrypt it; AppContainer blocks contained code from reading the profile. If secure storage is unavailable, a newly entered key is kept for the current session only and is not saved. You can save temperature, output-limit, and reasoning preferences per model; Nyx AI applies only controls that provider and model support. Switch models at any time. See every provider type.

Chat mode vs Nyx AI Lab

Chat mode is for conversation. If the model asks to use workspace-backed file/code/Git tools, or run shell or Python there, Nyx AI refuses the call before it runs. One Python path does stay open in Chat: pasting CSV text for analysis runs Nyx AI’s own fixed analysis code, and it always asks first — an in-app approval card with isolation on, or a full-permission Windows confirmation naming the exact file or data when isolation is off. Chat can still use chat-safe tools and create document download cards rather than workspace files. A card’s encoded bytes are stored with the local chat session so it remains available; clicking Download writes a normal file. Inline preview/runtime copies are short-lived. Refusing tools does not mean storing nothing, though: Nyx AI still writes its own local app data (chat history, memories, settings, usage and audit records), and a scheduled Chat task saves any document or file artifacts it creates under Documents\Nyxion\Scheduled. Nyx AI Lab is the workspace mode; toggle it with the pill at the top-left. Point Nyx AI at a project folder and it can read and edit files, run commands, search the codebase, browse the web and build documents in that workspace. Two things bound that power: Nyx AI’s file tools only reach folders you’ve approved, and how tightly commands and Python are locked down depends on the isolation level you’ve selected. Each session titles itself from your first message (a helper model may refine it), so a long session stays easy to find.

Interaction modes & the approval gate

You pick how much autonomy to grant, with four modes. Plan blocks workspace file changes and shell/Python execution. Read/status tools, approved web access, Nyx AI session state such as to-dos, and MCP tools whose advertised names are heuristically classified as read-only can still operate. Unknown names fail closed, but the name does not prove the server has no side effects. Default prompts you before any action classified for review. Auto-accept is a real handover rather than a shorter queue: routine file writes and shell commands run without asking, and you see the result rather than a prompt. It still stops for what its risk check flags — writes to files like .env, package.json or a repository’s git hooks, deleting a file at all, restoring a backup or checkpoint, sweeping multi-file refactors, running a script the model has just written, and shell commands it recognises as dangerous. Bypass can skip the remaining prompts too, including file operations flagged high-risk. It starts with a 60-minute deadline, can be extended in native-confirmed 30-minute steps, and is capped at four hours from the time of extension; it is never restored after a restart. Even then, model-authored high- and critical-risk commands and designated sensitive actions keep a native dialog or a fresh, one-off confirmation. When a prompt appears, read the proposed diff, command, or action details before deciding. The most sensitive consents go further: weakening the sandbox or the secrets-redaction filter, trusting a workspace, the dedicated dependency-install tool, each download of a new managed browser version, running a repository command outside the sandbox, turning Bypass mode on or extending it, adding or reconfiguring an MCP server, registering a shell-command hook, and sharing a document or a preview all use a native Windows dialog. AI-written Python raises one too, but only when it would genuinely run uncontained; while the sandbox is containing it — the default install — its approval is an in-app card like any other high-risk action. AI-written JavaScript run in the preview keeps its own native dialog. Saving a provider API key is gated the same way: the dialog appears only when the key would go somewhere other than that provider’s own default address or a service on this machine — on stock OpenAI, Anthropic or Ollama Cloud settings you see no prompt. That is not the whole list. One of those dialogs is wider than the rest. Allowing a repository command to run outside the sandbox also lets other repository-controlled commands in that workspace run without asking again until you close Nyx AI — including ones the model issues later, Git commands that change your files (checkout, switch, pull, merge, rebase, cherry-pick, am, commit), and anything run from the project’s node_modules/.bin, a folder project code can write to. The dialog says all of that before you click, the grant is kept in memory and never saved to disk, and commands Nyx AI rates high or critical risk still ask every time. Eligible raw package-manager commands instead ask in Default, follow Auto-accept or Bypass when network is allowed, and can be covered by a saved workspace/ecosystem grant. Why a system dialog? Because the model (or a compromised page) cannot click or pre-answer one. For ordinary risky model-issued actions, these prompts and the per-mode rules are the user-control backstop. Enabled Auto-verify uses its documented bounded prompt-free path; the guided Build pipeline has no entry point in the current free interface. Outside a Sandbox isolation level, one native Allow for repository-controlled execution covers later commands in that category in the same workspace for the rest of the app session, including later model-issued commands; high- and critical-risk commands keep their own confirmation. One more control sits beside the mode picker, and it is not an approval control. The tools pill chooses how much of the tool catalogue the model is shown: auto follows the model’s own profile, while minimal, focused and full override it for that chat. At the time of writing those tiers were 42, 69 and 123 tools; the picker counts them live from the shipped catalogue rather than quoting a stored number, so treat the pill as authoritative and these figures as indicative. Minimal is larger than the name suggests — file read and write, shell_run, document generation, web search and memory are all already in it — and focused adds browser control, code intelligence and read-only Git. Read the tool tier as a steer that keeps a small model on rails rather than as a boundary, and note it is unrelated to the sandbox tiers below: in the app’s own words it sizes the list the model sees and does not bound what it can reach, because it can still call another tool by name, and approvals, the active mode and the sandbox are all unchanged by it. The number also describes the Lab catalogue in both modes; Chat reaches far fewer, since most of those tools are refused where there is no workspace. How the sandbox works.

The sandbox (Windows)

When the model runs a command or Python, execution isolation decides how tightly that process is boxed in. Isolation is on by default, and you pick the level in Settings → Safety: Automatic, Standard, Sandbox + internet, or Sandbox · no internet.

The two Sandbox levels use Windows’ built-in sandbox, AppContainer, with and without internet access for the contained code. They fail closed: if the sandbox cannot start, commands are refused rather than run with weaker protection. Automatic prefers AppContainer after its launch test passes, but a later non-GUI AppContainer spawn can still fall back to Standard(a Job Object) if it fails. Partially applied or blocked policy states fail closed rather than downgrading, and shell, Python and the automatic TypeScript/refactor validators all enforce that. Standard is best-effort: a detected Job-limit degradation can be shown, but it does not fail closed. There is also a gap at the start: on Automatic and Standard, while a backend is still coming up and on a machine where neither can be created, a screened command can run with command and path screening only and no OS jail, which is why the tier badge — not the setting — tells you which level actually ran.

AppContainer is an OS-enforced write boundary: Windows itself stops writes outside the paths the sandbox has been granted. It is not a promise that everything outside is unreadable. Standard limits the process’s lifetime and resources and screens commands on a best-effort basis; it is not a filesystem jail. You can turn isolation off; commands and Python then run with your normal user filesystem and network permissions.

Some protections never turn off: file tools stay inside approved folders — with one exception, a chat-mode scheduled task, which runs with no workspace and writes to a dedicated folder in your Documents — commands are risk-classified, secret-shaped and known package-manager credential/source variables are removed from the environment by name on a best-effort basis, and the approval policy still applies. The always-on command floor runs before the app looks at which mode you are in, so it holds even in Bypass. Alongside the obviously catastrophic families (wiping a drive, fork bombs, piping a download straight into a shell, recognised privilege-escalation launchers and destructive elevated forms) it also refuses commands that reach for your stored credentials, that create filesystem links out of the workspace, that plant Git hooks, or that touch Nyx AI’s own .nyx control files. It is a pattern screen over command text, though, not a proof: some spellings get past any such screen. Treat it as a floor under the other controls rather than a reason to skip them. The specific patterns are deliberately not published, here or in the threat model. The wider list of dangerous Windows utilities is refused by default whenever an isolation level is active. A user can native-confirm a narrow, literal allow-list prefix for a single, unchained, unredirected command; this relaxes only the utility-name check, not absolute guards or hard refusals. Forms that Nyx AI classifies as high- or critical-risk need a native Windows confirmation in every mode and at every isolation level, including with isolation off; other forms follow the active mode’s normal rules.

Nyx AI runs on Windows 10 or 11 (x64) only. It is not supported, distributed, or tested on Windows on ARM, macOS, or Linux. No sandbox is ever 100%. Isolation reduces risk, and the approval gate is the final boundary. Read the threat model.

Workspace trust

A workspace not previously trusted is untrusted by default; trust persists for its resolved root until revoked. Until you explicitly trust it, Nyx AI will not run that workspace’s own executable configuration (its hooks, MCP servers or plugins) and will not start language servers for it or download their binaries. Why so careful? A project you didn’t write can include configuration that runs code, so that decision stays yours. Trust is granted one workspace root at a time, through a native Windows dialog that explains the main services it enables. Risky scheduled shell or code tasks are also held inert until trust. Trust also switches on something that list does not name, and the threat model states it precisely because a reader would not infer it: automatic verification. After a turn that edits files, Nyx AI runs the project’s own typecheck, test and lint commands — auto-detected from its package.json scripts when .nyx/verify.json does not pin a list. Only the wrapper command (say npm test) is risk-screened; the script body it executes is not, and the model may have authored that body in the same session. Outside a Sandbox tier those commands run project-authored code with your normal permissions and no further prompt. It is on by default — turn it off in Settings, or pin a fixed list in .nyx/verify.json. An untrusted workspace skips verification entirely, unless an AppContainer Sandbox is live, in which case it runs inside the AppContainer. The decision is stored in Nyx AI’s own profile, never inside the workspace, so a repo can never mark itself trusted. Changed your mind? Revoke trust any time in Settings → Safety. After a successful revoke, LSP and MCP processes stop, while hooks and risky schedules refuse on their next trust check. Already-loaded plugin command Markdown can remain until commands reload or the workspace reopens. The rule of thumb: only trust repositories whose build code you would run yourself.

Editing files & code

A full Monaco editor (the engine behind VS Code) with diff views sits alongside the agent. Nyx AI understands your code’s structure, not only its text (via tree-sitter). It can find callers, apply patches, rename symbols, and extract functions. Rename uses LSP when available; its TypeScript/JavaScript fallback is textual and marked unsafe, so preview and typecheck it. Function extraction works from a chosen line range and requires parameters to be supplied explicitly. Two safety nets sit under brokered safe edits, and they work differently: those tools take an automatic pre-write backup and refuse the edit if it fails; raw shell, Python, MCP, and background changes are not covered. Checkpoints are bounded save points created on request before a bigger change. Neither is kept indefinitely: backups are pruned past 500 snapshots or 14 days, whichever comes first, and only the 30 newest checkpoints are kept, each capturing at most 1,500 files and about 24 MB, skipping any single file over 512 KB along with binaries and the usual build and dependency folders. A file left out that way is not in the checkpoint at all, so there is nothing there to restore it from. Both reduce risk; neither replaces your own version control and independent backups. For broad but mechanical changes, the free app also has a bounded multi-file refactor worker for 2 to 50 named files, with up to five model workers. It applies outputs through the atomic safe-write batch only if no worker fails. When a compatible package typecheck/check script exists, a best-effort post-check rolls back on a definite non-zero result — but that post-check runs only under a Sandbox (AppContainer) tier, and only for a pinned tsc/vue-tsc entry. Under Standard, or with extra isolation switched off, it is skipped and nothing is rolled back.

LSP is enabled by default and starts only in a trusted workspace. TypeScript support runs inside Nyx AI and, once trusted, may load the workspace’s own node_modules/typescript and tsconfig without the separate project-code-execution setting. On Windows, pinned Pyright and Eclipse JDT LS builds can be downloaded and SHA-256 verified; rust-analyzer, gopls, and C# use a suitable system installation when available. Rust build scripts/proc macros and Java Gradle/Maven import remain off unless project code execution is separately enabled. That setting is not a universal gate for every language server, and the C# server does not currently honour it.

Auto-verify is on by default after completed edit-bearing turns and runs detected or configured checks. In an untrusted workspace it runs automatically only under live AppContainer isolation; otherwise it skips and /verify remains available explicitly. A failing check can trigger the configured number of repair turns. The default is one repair turn, and it runs only when the failure is attributable to a file changed by that turn.

Structured Git tools cover status, staged and unstaged diffs, add, commit, branch listing and creation, checkout, log, and stash. Optional auto-commit is off by default and commits only cleanly attributable brokered file changes; when Auto-verify is on and applicable it must pass first, and with Auto-verify turned off the commit runs without it. Pre-existing staged or dirty targets and ambiguous mutation paths are left for manual review. Nyx AI can also maintain a session-scoped to-do list shown inline and display an Approve, Modify, or Cancel plan card for large tasks. Plan approval does not bypass the active mode, isolation, or action-specific approval rules.

Shell & Python

The agent can run shell commands and execute Python to test, script and inspect. Shell commands pass the shell command screen and use the active execution backend when one is live. Python has its own approval and execution path, and asks for a native full-permission Windows confirmation whenever it would genuinely run uncontained. See the Security limitations. The most destructive command families are blocked in every mode. The wider list of dangerous Windows utilities is blocked by default whenever an isolation level is active, subject to the narrow native-confirmed allow-list exception described above; with isolation off, forms that Nyx AI classifies as high- or critical-risk need a native Windows confirmation, while other forms follow the active mode’s normal approval rules. The rest are graded by risk and handled under the active interaction mode, and high- and critical-risk commands keep their extra controls in every mode.

Installing packages has its own path: the dedicated dependency-install tool raises a native Windows dialog, titled “Install a dependency from the internet?”, naming the packages and the registry the request is aimed at. Project configuration can redirect some package managers to another source or mirror. Approved Python and CSV actions can also fetch a small allow-listed, wheels-only package set on first use; that download is named in the action approval and is blocked by the relevant no-network settings. If the model types a raw package-manager command instead, Default mode still asks for that same native consent; Auto-accept and Bypass let it follow the active interaction mode. A grant you saved for the workspace can cover later installs in that project; if the network is blocked, Nyx AI asks again. Two things a grant never covers, however often you have approved that ecosystem: a global install (-g, cargo install, pipx and their equivalents), and any command pointed at a non-default registry or index. Those always ask, as does anything the risk check rates high or critical. Both dependency dialogs open with Cancel as the selected button, so pressing Enter declines — as do Escape and closing the window — and allowing takes a deliberate click on Allow. That is recent and deliberate: until v1.5.460 the raw-command dialog opened on Allow once, where a reflexive Enter approved an install.

You can also run commands yourself. Nyx AI has its own Terminal panel, and a Run control that executes the file you have open. Neither is a way around the rules: both go through the same broker the model’s commands do, with the same screening, the same risk grading, the same native Windows confirmation for a high- or critical-risk form, and the same audit record — and, since v1.5.472, that dialog states where the request came from — the Terminal panel or a Run control rather than the AI model. Treat that line as a label rather than a proof: it is declared by the app’s own interface and is display-only, so no gate, risk rating or grant decision reads it. It cannot make a dialog more permissive than the AI-model default, and the dialog tells you to refuse if you did not just perform that action yourself. What they no longer do is feed the chat. Since v1.5.480 a command you type there, and its output, never enter any conversation’s context. Before that, a surface with no chat of its own attached its activity to whichever conversation happened to be mid-turn, so a command run while one was streaming — and up to 2,000 characters of what it printed — was appended to that session and sent to the model on its next turn. Both surfaces display their own output, so nothing is lost by not showing a chat card. One neighbouring case is not closed, and is named here so this does not read as more than it is: saving a file by hand still posts an activity entry into a conversation that is streaming, where it can look as though the assistant made that edit. That one is cosmetic — it does not reach the model.

Generating documents

Start from 12 fill-in templates in either mode. Importing and mapping CSV, TSV, JSON or XLSX data from a file is Lab-only; Chat’s one data path is CSV analysis on text you paste in. In Lab, Nyx AI writes formatted DOCX, XLSX, PPTX, PDF, and ODT files plus standalone, compilable LaTeX (.tex) source. Chat download cards support DOCX, XLSX, PPTX, and PDF; ODT and the dedicated LaTeX writer require Lab. Excel workbooks can include live formulas, number formats, conditional formatting and data validation. That means a financial model that recomputes, not a table of pasted values. An existing document can be patched precisely: Word and Excel replacements can keep formatting, and a replacement-only PowerPoint edit patches matching text in place when the match is contained in one text run. Complex Word appends containing media, links, or LaTeX can rebuild or flatten content. Appending slides builds a new deck from extracted slide text; existing layouts, images, charts, tables, shapes, notes, themes, and animations are not retained. Formula cells are protected from being silently flattened into plain numbers. Nyx AI can also read back PDF, DOCX, XLSX, and PPTX files to answer questions about them. If a document tool fails, it includes detailed failure information when available (for example a malformed request, full disk, or file open in another program). Lab tools save documents in the workspace; Chat keeps each card’s encoded bytes with the local session, and Download writes a normal file. Want to hand one over? In Lab, you can share a workspace document through a temporary link that works only on the same machine (localhost-only, 60 minutes by default). Starting one needs approval in a native Windows dialog rather than an in-app prompt, and that dialog names the file, its size in bytes, how long the link lasts, and the workspace. The file is re-checked by hash after you approve, so a file swapped during approval cancels the share, and the live link re-checks size and hash on every request as well — edit the file after sharing it and the link stops rather than serving the new bytes. Two hard limits apply before that dialog even appears: a file over 64 MiB is refused outright, and the expiry must be a whole number of minutes from 1 to 120— anything else is refused rather than quietly rounded back to the default. A separate preview share can show a web preview to devices on your local network, for about 30 minutes, behind a secret token carried in the link. Advanced users can manually configure a compatible Google Drive MCP server. Each server carries a Capability setting — Full access, Read + write, or Read-only — which the main process enforces fail-closed: under Read-only a tool whose name is not a read verb is refused, and a name it cannot classify counts as a write and stays blocked. You can switch that server’s individual tools off by name on top of that. Both are limits on the names a server advertises, not proof of what it does internally, and Full access is the default. If the server later changes the tools it advertises, Nyx AI withholds all of them until you remove and re-add it, so a server cannot quietly grow a new capability past a choice you already made. How names are read was tightened in v1.5.460, and it is the kind of change you meet after an update rather than at setup. Some tools a Read-only server used to run are now classified as writes and refused, because a name that mentions a mutating or executing action is treated as one wherever that word sits, not only when it leads. A few camel-case read names went the other way: they used to fall to the fail-closed default and be blocked, and are now recognised as reads. If a read-scoped server’s tool stopped working after an update, that is why — re-scope the server, or take it up with the server’s author. Classification remains a heuristic over the advertised name, not proof of what the server does internally, which is why Read-only is a floor to combine with trusting the server rather than a substitute for it. Two limits are specific to the free build. The curated one-click preset catalog is not included, so servers are added by hand. And because email and Telegram are Pro features removed at source here, Nyx AI also refuses MCP servers and tools that would send mail or Telegram messages — a product boundary rather than a security guarantee, since it recognises the obvious cases by name and description rather than by what a server actually does.

Live preview

For web work, Nyx AI manages a local dev server and drives a headless browser (Puppeteer), so it can interact with and test what it built. It can take screenshots, inspect the page, read console and network logs, and click, type and navigate. Three caveats. The dev-server launcher only accepts commands it rates below high risk: npm run dev, vite, http-server and python -m http.server start a preview, while it rules out most npx <package> launchers (npx serve is specifically allowed) and direct interpreter-plus-script launches such as node server.js or python app.py, even though those are ordinary dev servers. Nyx AI calls that a limit of the preview tool rather than a fault in your command; you can still run the refused command with the shell tool, without a preview pane. And that headless browser is not bundled: Nyx AI uses an installed Chrome, Edge or Chromium when it finds one, and otherwise asks in a Windows dialog before downloading a headless build once and caching it for later. Only the browser-driven tools need it — building documents, PDFs included, renders inside the app. By default, PDFs open in a software-rendered built-in viewer, improving preview reliability on VMs, remote desktops and machines where GPU acceleration is unavailable. An advanced environment override can leave hardware acceleration enabled, and a badly failing graphics stack can still prevent the app starting. The built-in preview uses loopback by default; project commands and custom profiles may bind a different address, including the LAN. Want to check a page on your phone? A separate, opt-in LAN share can show one to devices on the same local network, over Wi-Fi or Ethernet, for about 30 minutes, behind a link that carries a per-share secret token. That one needs approval in a native Windows dialog too, naming the preview, the command behind it, the workspace, and the service port, and you can switch LAN sharing off completely in Settings under Safety, with “Allow LAN preview sharing (open the preview on your phone)”. That master switch ships on, so the capability is available until you turn it off — though no share ever starts without its own approval. With it off, no LAN port is opened at all. Know what that link means: anyone on that network with the exact link can open it until you stop it or it expires. Opening or reloading a page always needs the token in the link; cookies and referer headers only help a page load its own images and styles.

MCP servers, plugins & hooks

An MCP (Model Context Protocol) server is an add-on that gives the AI extra abilities. Some run as programs on your own PC; others are remote services reached over the web. Compatible remote HTTP/SSE servers can use auth-code PKCE after you click Authorize. Servers connect only in a workspace you’ve trusted. If a recognised local runner (npx, uvx/uv, a Python launcher, node, or docker) is missing, Nyx AI links to its publisher’s official download page; install it yourself, then reconnect. Know where an add-on’s power sits: add-ons that run on your PC use your user permissions by default. The experimental Sandbox MCP servers control routes eligible stdio servers through the active execution backend: AppContainer under a Sandbox tier or best-effort Job limits under Standard. Job assignment can degrade with a visible warning. Remote servers run on someone else’s machines, outside those process-containment controls. Nyx AI Lab can also register a runtime tool around one allowlisted shell command. Placeholder values are escaped, and the filled command is screened by the same rules as a command the model types. Two limits are worth knowing before you register one. It does not survive a restart, in either scope: the file it would be saved to is one of Nyx AI’s own protected control files, so the save is refused and fails silently; nothing reaches disk and nothing is reloaded next launch. (The app still describes these tools as persisting; that wording is a known error in the product, recorded in its own changelog.) And treat the displayed risk grade as advisory rather than as a verdict on the command: outright dangerous commands are blocked and the approval card shows the exact command that will run, but the in-app grade follows the tool’s name rather than what its command actually does, so under Auto-accept a custom tool whose command is risky but not outright blocked can run without an in-app card. Review a custom tool’s command before enabling Auto-accept. The native Windows confirmation the desktop app raises for high- and critical-risk commands applies to these commands too, whatever the tool is called. Plugins deserve the same care, with one caveat about this build: it ships no way to browse, install or enable one from the interface, so unless a plugin is already present on disk you will not meet the flow at all. The machinery, and the native Windows dialogs guarding it, are otherwise complete. A plugin’s commands are plain Markdown files, but a plugin can also add MCP servers and hooks, and those are executable. One thing to understand before installing either: the always-on command floor described above screens the commands the model writes. Hooks and MCP servers are treated as code you authored, so that screen is deliberately not applied to them — which is precisely why trust is the gate. Ambient secret-shaped environment variables are stripped by name on a best-effort basis from them; values explicitly configured in an MCP server's own environment are deliberately preserved and passed to that server. With Sandbox lifecycle hooks (experimental), AppContainer is the real Sandbox-tier boundary. Standard provides best-effort Job limits, and a Job-assignment failure can let the hook continue with a wrapper warning. If no configured isolation backend is live, or a contained start throws, the hook is refused. Install only servers and plugins you trust.

Automation & notifications

Scheduled tasks(free) are stored and armed for the currently open workspace. Switching workspaces loads that workspace's schedules. Schedule a task every N minutes (60 seconds minimum), hourly, daily, weekdays, weekly, monthly, or with a cron expression. Creating a Chat task with no workspace open is refused, not saved for the session: there is nowhere to store it, so Nyx AI reports that nothing was changed and no task is created. Open a workspace first. Missed runs are skipped by default. Each task has its own unattended-approval choice; arming shell, code-editing, or Bypass risk requires a native confirmation. What a scheduled run can write is narrower than what the app writes interactively, in both modes: PDF, Word and plain text files only. There is no scheduled spreadsheet or deck writer, and an .xlsx or .pptx path comes back refused with a message saying the refusal is final and cannot be overridden. So schedule those three formats, or schedule a task that gathers the data and build the workbook or deck yourself. On the reading side the modes differ: a Lab task reads files in its workspace, and edits them only on the code tool tier, which is what the native confirmation above is arming; a Chat task gets web tools only and never reaches a workspace at all. Tasks also need Nyx AI itself to be running, and by default closing the window quits the app, which stops the schedules with it. To keep them armed, turn on Keep running in tray when window closed in Settings → Advanced: closing the window then hides Nyx AI to the system tray instead of quitting, and you exit fully from the tray icon. There is no Windows service and no background agent— nothing runs when Nyx AI is not running, so a task whose time passes while the app is closed is just a missed run. Notify: Always (the default) sends a result to the Scheduled tasks chat and an in-app toast. Notify: On failure does so only for failures, while Notify: Never suppresses that UI delivery. Chat-mode artifacts are still saved under Documents\Nyxion\Scheduled. Those three settings decide whether a result is delivered; a fourth rule decides whether it can be. A Lab task’s result carries the identity of the workspace it was created in, and one that arrives while a different workspace is focused is dropped rather than shown, with nothing replaying it afterwards. Chat tasks are deliberately different: they carry no workspace tag, so their results are delivered wherever you happen to be working. You are told rather than left guessing: a toast says the task ended in the workspace it belongs to and that its result is not kept. What survives is its last-run status, in that workspace’s Scheduled tasks panel. So Notify: Always is a promise about the workspace that owns the task, not about wherever you happen to be working. Separately, a guided build pipeline — a setup gate, web research, a plan you approve, a parallel build, an integration pass and a QA review — is written and has a finished interface, but nothing in this build can open the setup gate, so it cannot be started. The Pro roadmap goes further, though it is not currently for sale and its scope and timing may change: general-purpose delegated sub-agents, Telegram remote approvals (approve actions and read task output on your phone), and email using a mailbox you connect. The Telegram and email code is absent from the free build, not merely switched off. What is free vs Pro.

Memory

Nyx AI keeps global preferences in its local app-data store and, in Lab, project facts in the current workspace. Chat recalls only global memory; Lab can recall both. Nyx AI does not upload either store to NYX LIMITED, but a recalled snippet can become part of a request sent to the model route you use.

Action audit + forensic logs

When logging is available, approval-queue requests, grants, and denials handled by the approval-policy manager, plus mode and sandbox block/state events, are written to the encrypted Forensic log whose entries are chained together, so a change to a recorded entry can be detected. In Settings → Safety, under Action audit + forensic logs, Verify chain re-checks it in place and Save decryption bundle writes the encrypted log, its key, a standalone decryption script and a README with the verify result, so someone else can check it without Nyx AI. That bundle contains the key, so share it as carefully as the log itself. Three honest limits: the log cannot prove that nothing is missing, it is not a backup, and because the key is on this machine it is a self-check rather than evidence for an adversarial party. Also worth knowing: standalone native-confirmation paths are not universally represented there, and refusals from the always-on command floor are returned to the model as errors and written to neither log. The separate plaintext Action audit log records scrubbed tool calls and approvals for everyday debugging. One setting controls both logs. More on the logs.

Privacy & secret redaction

Before text reaches a cloud or otherwise off-machine model route, the privacy sanitizer (a filter on outgoing text, in Settings → Privacy) redacts secrets by default (the secrets-only preset). You can turn the sanitizer off, which sends off-machine model text without that filtering. The standard, aggressive and paranoid presets also redact progressively more personal data such as emails, paths and IPs. Phone numbers are part of that group, and the coverage is newer than it looks. Until v1.5.464 the rules matched US formats only, so ordinary UK numbers — 07700 900123, 07700900123, +447700900123 — went through untouched at every preset, paranoid included, while the settings copy promised phones from standard upward. They are redacted from standard upward now, and still deliberately left alone at secrets-only and minimal, where the phone category is off. It stays pattern matching in both directions: shorter and less common formats are deliberately not matched, because the false-positive cost outweighs the reach, and going the other way an eleven-digit reference number sitting in a sentence is redacted as though it were a phone number. The remaining preset, minimal, is not simply a weaker one: it adds credit-card and US Social Security number redaction but stops catching password=-style assignments, Google, Slack, Discord and Stripe tokens and database connection strings, which the default does catch. Because that drops protection, moving to it needs the same native Windows confirmation as switching the sanitizer off. The current message and attachments show a receipt for their redactions. A final egress pass can also scrub older history, tools, and tool results without a separate receipt. The sanitizer is best-effort pattern matching and does not see image pixels; add-on (MCP) and web-fetch traffic follow their own paths. An ordinary prompt routed to a model on your own PC is not sent to a cloud provider. Automatic helpers can still fall back to an eligible cloud route despite local-routing preferences; the separate local-image control, off by default, hard-blocks only a local-model image handoff to cloud vision — with it off, that handoff is what ships. Read the privacy policy.

Updates

Nyx AI checks for updates automatically. The check is on by default; turn it off in Settings → Advanced → Updates. It asks an update host we operate, served via Cloudflare, whether a newer version exists, and tells you the answer. The request carries your IP, app version, and standard request metadata. It never downloads or installs anything on its own; you decide. Public distribution builds are digitally signed by NYX Limited. When you do update through the app, every request — including every redirect — must stay on the update origin, and the version listing itself is fetched under a size cap and a timeout so a hostile server cannot stall or flood the check. Before the installer runs, it must pass strict checks: its SHA-512 hash, the full Authenticode publisher identity (the digital signature), a block on rolling back to an older version, and an exact match of the version signed into the file. Downloading and installing each ask for their own native confirmation. Manual browser and portable artifacts sit outside that verified in-app route; this website currently offers neither.

See also

The Features page is the quick capability list; Security and the threat model spell out the guarantees and their limits; Getting started walks you through setup in order; and Why Nyx AI shows how all of this compares to the usual options.