Why Nyx AI
Turn files into finished work on your Windows PC.
Nyx AI is a local-first AI coding workspace with agentic tools: it builds documents, spreadsheets, presentations, and code using the AI you choose. A model running on your own PC can keep the AI's work and your project's content there, or you can bring your own cloud key. No Nyx AI account; the app itself sends us no usage tracking, analytics or crash reports. Its four isolation levels are Automatic, Standard, Sandbox + internet, and Sandbox · no internet. Extra isolation also has a separate off switch; when off, commands run with your normal user permissions. The app shows which level is actually running, and how much needs your approval depends on the mode you choose.
It runs on your PC.
A Windows desktop app you install and license, not a browser-only service.
One app with the editor, the AI agent, its tools, the sandbox controls, and the document builders all inside. Two things are not inside it. The AI is the first: there are no bundled models and no inference engine, so to run a model on your own PC you also install Ollama, a separate free program, keep it running, and pull a model into it first. Nyx AI links you to that download when it doesn't find one. The second is the automation browser behind screenshots and page reads: Nyx AI ships no headless Chromium for that and uses an installed Chrome, Edge or Chromium, or asks in a Windows dialog before downloading one.
Privacy choices are visible.
Choose where model inference happens.
Point Nyx AI at Ollama on a loopback Base URL — loopback meaning the daemon answers on this same PC — and ordinary prompts can stay here only when the selected model really runs locally rather than using Ollama Cloud. Other routes are off-machine. Current builds treat Ollama model names ending :cloud or -cloud as off-device for labelling and for model-text sanitization when that sanitizer is enabled. On Auto, heavier coding, reasoning and planning turns normally prefer a cloud route; smaller background helpers prefer a suitable local model but may fall back to cloud.
Containment is selectable and visible.
You choose how tightly its code is contained.
Isolation is on by default. Automatic prefers AppContainer after its start-up test passes, but a later non-GUI AppContainer start can still fall back to the weaker Standard level if it fails; briefly at start-up, and where neither backend can be created, a screened command can run with no OS jail at all, so the tier badge is what tells you which level ran. Explicitly selected Sandbox levels refuse commands if AppContainer cannot start. You can turn isolation off, in which case they run with your normal user permissions. For ordinary risky model-issued actions, the selected mode and approval policy form the user-control backstop; enabled Auto-verify has the bounded prompt-free path described in the threat model, and 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. Designated sensitive operations keep a system dialog or fresh one-off decision. Two logs record what happened, and the controls section below states what each covers and where it stops. No sandbox is 100%.
The state of the market
Trust is a policy. Containment is architecture.
Most AI-agent tools ask you to trust the agent, or the company behind it. The cards below describe common tendencies of each tool category, not claims about any one product. Each was checked against public vendor documentation in July 2026.
Execution boundaries vary
Some tools run commands directly with your full user permissions, or offer modes that ask less often. Others use local or cloud sandboxes. Check each product's current behaviour rather than assuming the word “agent” means the AI is walled in.
Mistakes are not hypothetical
Agents act on instructions, and instructions can arrive from a web page, a README, or a file the agent was asked to read. Published vulnerability reports and prompt-injection research keep showing the same lesson: containment, review, backups, and a record of what ran matter more than the agent's good intentions.
The cloud is the sandbox
Hosted agents are typically sandboxed in the vendor's cloud, so the files and prompts needed for that work are sent there. An account is often required, and handling and retention depend on the product and plan.
Accounts and pricing vary
Major vendors now mix free access, usage limits, and paid power tiers. Many use a vendor account and bundled models. Nyx AI sits outside that pattern on both counts, and the account and cost rows below give the exact position.
Nyx AI’s answer is architecture rather than a promise. On supported Windows systems the walls are built into the operating system itself — the same AppContainer mechanism Windows uses to box in Store apps, set up here for a workspace rather than a packaged app, and applied to the commands and Python code the AI runs. The limits are stated plainly: a sandbox shrinks the damage a mistake can do, it doesn’t make an agent safe. For ordinary risky model-issued actions, the mode you choose and dialogs the AI can’t fake form the user-control backstop. Enabled Auto-verify has the bounded prompt-free execution described in the threat model; 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 usual options
Three familiar shapes of AI help.
No brand names here on purpose: these are honest tendencies of a category, never a verdict on a particular product. Plenty of them are good tools. They just make different trade-offs.
Cloud-based AI coding IDEs
These products vary: some do the work on remote servers, some on your machine, and their privacy, data-retention, training, and isolation settings differ by vendor and plan. Nyx AI's position: you pick where the AI runs — a model on this PC, a remote Ollama endpoint, an Ollama “:cloud” or “-cloud” model, or your own provider key — and its Windows boundaries are documented.
Cloud AI chat & agent subscriptions
Major assistants now create finished Office files and can work with local files on desktop. They still run on the vendor's own account and models; cloud sessions and connected services follow that vendor's policies. Nyx AI instead lets you choose a local model or your own cloud provider.
Autocomplete-first plugins
Code suggestions as you type are still the heart of these tools, though some now add agents, tests, and broader workflows. What documents they can build, how they contain the AI, where your data goes, and what they cost all vary, so compare the exact plan you would use.
Side by side
What matters, and where it lands.
Scroll sideways to compare
| What matters | Cloud-based AI coding IDEs | AI chat & agent subscriptions | Nyx AI |
|---|---|---|---|
| Where your work goes | May be processed on your machine, by a model provider, or on the vendor's systems; retention and training controls vary by product and plan | Desktop agents can work with local files; cloud chats, connected services, and synced sessions follow the vendor's policies | With Ollama on a loopback Base URL, ordinary prompts can stay on this PC only when the selected model really runs locally; a remote Ollama URL or any cloud-proxied Ollama model, including names ending :cloud or -cloud, is off-machine. Current builds label both cloud suffix forms off-device and apply the model-text sanitizer when it is enabled. On Auto, heavier turns and automatic helpers can use an eligible cloud route, and off-machine model routes receive the context assembled for that request after best-effort secret scrubbing when the sanitizer is enabled. One handoff goes the other way by default: if your local model cannot read images, Nyx AI hands the image to whichever vision-capable model its provider list offers first, which can be an eligible cloud route even when you have a local vision model installed, and it tells you before the bytes leave. A Privacy setting, off by default, blocks that cloud handoff and degrades to text instead; if no vision model can be reached the call fails and the image is not analysed. Long-term memory is the one part with no cloud route to choose: the embeddings behind it are computed on this PC only, with no setting that changes it, and if the local embedder isn't running, recall falls back to keyword matching rather than reaching out. The separate codebase index is not the same — it does have a cloud embedding option, used only when you explicitly build the index that way |
| Who provides the AI | The vendor's bundled models, on the vendor's terms | Typically the vendor's hosted models, with availability depending on the product and plan | You choose: a model on your own PC, a keyless remote Ollama endpoint, an Ollama “:cloud” or “-cloud” model through a daemon you signed in to locally (no key kept in Nyx AI, but it still runs off-device), or your own cloud-provider account with your own key; Nyx AI resells no AI service |
| Works on your real files | Yes; processing location varies by product and configuration | Yes, including newer desktop modes that can use local files with permission; availability and limits vary by plan | Yes: it reads, edits, and reworks files in your workspace. Brokered write/edit tools can show proposed diffs and take best-effort backups of eligible files; raw shell, Python, MCP, and background mutations do not have guaranteed per-file diffs or those backups. Checkpoints are available on request |
| Runs commands and tests | Execution can be local or remote; isolation and approval controls vary by product and configuration | In a vendor cloud sandbox or on your machine in newer desktop agents; check the vendor's current documentation for the exact boundary | With isolation on, the Sandbox levels use Windows' own sandbox to stop commands and Python writing outside approved folders; the Standard level applies lighter limits and screens commands and paths, but does not wall off your files. Briefly at start-up, and where neither backend can be created, a screened command can run with no OS jail at all. Isolation off runs with your normal user permissions |
| If the AI tries something risky | Varies, some tools just run it | Vendor-defined approvals and guardrails, with controls that vary by product and plan | For ordinary consequential model-issued actions, Default pauses with the proposed diff or action details on screen, and the most sensitive decisions escalate to a Windows dialog the AI cannot fake. Enabled Auto-verify uses a documented bounded prompt-free path; the guided Build pipeline is not reachable in this free build. 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 — until you close Nyx AI, not until you start a new chat; high/critical commands keep their own confirmation. Quieter modes exist only if you select one |
| Real documents, not just text | Varies: many remain code-first, while some now support broader finished artifacts | Yes, major assistants now generate finished Office files; desktop local-file modes and cloud modes have different storage paths | Builds real files locally: Excel with live formulas, Word, PowerPoint, and PDF, plus ODT and compilable LaTeX source in Nyx AI Lab, and targeted edits with documented limits. Replacement-only PowerPoint edits preserve the existing deck; appending slides builds a new text-based deck and does not retain existing layouts, images, charts, tables, shapes, notes, themes, or animations |
| Web research | Some agents browse, through vendor infrastructure | Often; hosted browsing may be tied to an account and varies by product and plan | Yes: search, page fetch, and deep research run from your machine, behind a URL screen the model cannot talk its way past. http and https only. Loopback, private, link-local and cloud-metadata destinations are refused, including a public hostname that resolves to one of them — and a DNS lookup that fails or comes back empty is refused too, rather than given the benefit of the doubt. A URL carrying a secret or key is refused, raw or percent-encoded. Look-alike internationalised hostnames are refused, and so are direct executable and installer downloads. Every redirect hop is put through the whole screen again before it is followed. Resolving the name and checking every answer closes the ordinary DNS-rebinding case; it is not socket-level pinning, so it does not stop an attacker who can flip a record between that check and the connection. Requests asking to read up to three pages are unmetered. Four deeper requests are allowed per guarded metering window; after that, deeper requests are capped at two fetched pages until the reset, and a relevant Wikipedia lead may also be added. Note which one everyday use lands in: a search that doesn't ask for a page count reads six pages by default, so it counts as a deeper request rather than an unmetered one. Three controls in Settings → Safety cut Nyx AI's built-in model web, image, and document-fetch paths, and all three ship on, so they are open until you close them: the “Allow the assistant to access the web” switch; turning off “Allow internet access for AI-run code” or choosing Sandbox · no internet, which refuses those tools as well as sandbox egress; and, for documents only, “Auto-fetch images in generated documents”, which stops the illustration downloads and image searches without touching the rest. Model-provider, MCP, hook, and ordinary command traffic have separate controls |
| Telemetry and accounts | Often account-based; usage analytics and controls vary by product and plan | Usually account-based; conversations and files may be retained under the vendor's policy and settings | No Nyx AI account, and the app itself sends us no usage tracking, analytics, or crash reports. For Microsoft Store installs, Microsoft separately gives the publisher mostly aggregate store reports, and their Health data can sometimes include event-level detail such as an individual stack trace or crash-dump file. The default-on update check is the one routine connection back to us: it carries your app version and IP, and you can turn it off |
| A record of what the AI did | Evidence and logs vary by vendor and plan, especially on business and enterprise tiers | Conversation and activity records vary between local and cloud modes and by vendor plan | Two logs, kept on this PC when logging is on and working: a plaintext Action log of scrubbed tool calls and approvals, and an encrypted, chain-hashed Forensic log you can verify offline — a self-check, not evidence for an adversarial party, since the key is on this machine. What each one does and does not capture is set out under the controls below |
| What you install | Typically an IDE or extension connected to vendor or model-provider services | Typically a browser tab or desktop app connected to hosted services | One Windows app: editor, agent, sandbox, search, previews, and document builders built in. It ships no automation browser and no AI model: documents and previews render with the app's own embedded Chromium, but screenshots and page reads use a system Chrome or Edge, or a Google browser build it asks before downloading, and a model on your PC needs Ollama installed separately |
| What it costs | Typically a per-seat subscription | Free access and paid tiers vary by vendor, plan, and usage | The personal beta licence is £0 for personal, non-commercial use; you pay only your own model provider (or nothing, with a model on your own PC), with no markup on AI usage |
Category columns describe common tendencies of each tool type (“typically”, “often”), not any specific product, and are not a claim about any individual vendor. They were checked against public vendor documentation in July 2026. Individual products differ and change, so always check a vendor’s current terms. The Nyx AI column is verifiable: the threat model lists the known network connections the product makes and states their limits, and the security page spells out what each protection covers and where it stops.
Built in from day one
The controls security reviews now ask of AI agents.
Keeping the AI’s writes inside the workspace, controlling its internet access, requiring human approval, and keeping a record of what it did have become the standard asks for AI-agent tools. Nyx AI ships them as the architecture, not as an add-on.
Its file tools write only where you allow
Nyx AI's file tools only accept paths inside your active workspace and any folders you've explicitly allowed. AppContainer permits model-issued shell/Python writes to the workspace, user-added allowed folders, and Nyx AI-managed scratch, dependency, and temporary locations. Existing root .nyx controls receive a recursive deny, and literal .nyx targets are refused by command and file-tool screens. This is a strong path lock, not an absolute immutability guarantee: already-approved contained code can still exploit path replacement. Git controls are protected in the root repository, linked metadata and a bounded best-effort scan of nearby nested repositories; deep, skipped, unreadable, new or recreated paths remain residuals. Narrow toolchain/interpreter grants are read/execute, not write. Standard is not a filesystem boundary.
Control over its internet access
Sandbox · no internet blocks ordinary model-issued shell/Python and their descendants at the OS level, and separately refuses Nyx AI's own web search, page fetch, deep research and image-fetch tools; the automation browser the model drives for screenshots and page reads honours the same setting. A separately approved dependency operation can receive a narrow temporary network path; ordinary commands cannot grant themselves that exception. The threat model separately names integrations and components outside this boundary.
Human approval on risky actions
Default can run eligible low-risk writes and shell commands automatically, while higher-risk ordinary model-issued actions wait for you with the exact change or command shown. Auto-accept and Bypass ask less only when you choose them. Enabled Auto-verify has a documented bounded prompt-free path; the guided Build pipeline is not reachable in this free build. 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 — until you close Nyx AI, not until you start a new chat, including later model-issued commands; high- and critical-risk commands keep their own confirmation. The most dangerous command shapes the model writes are blocked outright in every mode. Hooks and MCP servers sit outside that screen as code you authored, so they remain locked behind workspace trust instead.
Consent the AI can't fake
Sensitive decisions use a real Windows dialog that neither the AI nor a hijacked web page can click. Examples include weakening protections, trusting a workspace, using the dedicated dependency installer and downloading an exact managed-browser version. A raw package-manager command still raises that same dependency consent in the default mode; Auto-accept and Bypass let it follow the mode instead, and a grant you save for a workspace covers later installs there — except with network blocked, which asks again. One Allow is wider, and the dialog says so before you click: approving a repository-controlled command covers that workspace's other repository commands for the rest of the app session — until you close Nyx AI, not until you start a new chat — including ones the AI issues later. It is kept in memory only, and high- or critical-risk commands still require a fresh native confirmation or are refused.
Unknown projects start untrusted
A workspace you have not previously trusted cannot run its hooks, MCP servers, language tooling, or risky scheduled code until you explicitly trust it. Trusting it also turns on automatic verification, which runs the project's own typecheck, test, and lint scripts after the AI edits files — only the wrapper command is risk-screened, not the script body, and outside a Sandbox level those scripts run with your normal user permissions. Decline trust and automatic verification is skipped instead, with one carve-out: if AppContainer isolation is actually live, which includes Automatic whenever its launch probe passed and not only an explicitly picked Sandbox level, it goes ahead inside that container. Running /verify yourself is your own instruction and is unaffected either way. Trust persists for that resolved root until revoked, and a project cannot mark itself trusted.
A record you can check
When logging is available, the plaintext Action audit log records scrubbed tool calls and approvals. The encrypted, chain-hashed Forensic log records approval-queue requests, grants, and denials handled by the approval-policy manager, plus mode changes and sandbox block/state events. Standalone native confirmations are not universally represented there, and always-on command-floor refusals are returned as errors instead. Checking the chain offline shows whether a recorded entry was changed, but cannot prove nothing is missing and is not evidence for an adversarial party, because the key is on this machine.
A last check before secrets leave
If a renderer tool reads a path or content treated as sensitive and a later renderer tool call in that session is classified as external, a native “Don’t send” dialog asks before that call. This is pattern-based and per-call; it does not cover every possible egress path.
Updates that can't sneak in
The update check tells you a newer version exists and stops there: nothing downloads or installs on its own. If you choose to update, the file that describes the update and the installer itself both have to come from the one update origin the app pins — redirects included, with no fallback to an unchecked path. The installer's checksum (SHA-512), digital signature and version are then all checked: the signature against our full certificate identity rather than a name alone, and the version both against the version stamp inside the downloaded file and against the newest version this installation has already verified, so an older build can't be rolled back onto you. A second confirmation, in a Windows dialog, is needed before it installs. Downloads you fetch by hand sit outside those checks, so verify their signature and published checksum yourself.
Where we’re honestly not ahead
The trade-offs, stated plainly.
The caveats are part of the product. When a deletion can’t remove everything, the app lists what’s left instead of rounding up. The same honesty applies here.
Closed-source
Some rival tools that also run on your PC are open-source, so anyone can read their code in a way Nyx AI’s can’t be. Our answer is verifiable behaviour: the threat model is published in full — it names the boundaries and the residual risks we know of, and deliberately withholds only reproduction and detection mechanics — and you can watch what the app actually does with your own network monitor.
Windows-only
Nyx AI is Windows-only. It runs on Windows 10 or 11 (x64) and is not supported, distributed, or tested on Windows on ARM, macOS, or Linux. The approval gate, workspace containment, Action audit log, and Forensic log are part of the app; the kernel-level OS sandbox relies on Windows-specific features.
Beta software, AI output
Nyx AI is in beta, and AI output can be wrong, incomplete, or insecure. Review, test, and verify before you rely on it. None of the containment above replaces that, and the terms say so plainly.
Nyx AI works with you. You decide.
You pick the model, the containment level, and the mode. Local Ollama needs no API key, or bring your own cloud key.