u/nyxlimited2

I'm the developer, and this is my project, so read it with that in mind.

The part I think is actually interesting is a refusal, so I'll start there. My app can run AI-generated shell commands and Python inside a Windows sandbox using AppContainer. Before it treats a sandbox level as available, it tests on your machine that Windows is actually enforcing that boundary, and it fails closed when a sandbox level you chose can't be established: the command is refused rather than run with weaker protection. The UI always shows which isolation level actually ran, because "sandboxed" is a claim and the app should have to prove it.

The app is Nyx AI, a Windows desktop workspace built around an AI agent. It does documents, spreadsheets with live formulas, slide decks, PDFs, web research and data analysis as well as code editing and shell work. You bring your own model: Ollama running on your PC with no API key stored in the app, or your own OpenAI, Anthropic or Ollama Cloud account. It ships no models and no inference runtime, so local means installing Ollama yourself first.

Honest qualifier on "local-first", because you'd catch it anyway: a local Ollama model keeps ordinary prompts on your PC, and small background helper calls can use a local model when one is available. On the Auto routing setting, though, heavier coding, reasoning and planning work normally prefers a cloud route you've configured. Local-first is a supported way to run it, not a guarantee that nothing ever leaves the machine. The docs say exactly that.

There are four isolation levels: Automatic, Standard, Sandbox + internet, and Sandbox · no internet. They use two Windows mechanisms: AppContainer for the two Sandbox levels and a Job Object for Standard. Standard is documented as not being a filesystem or network jail.
At the no-internet level, the sandbox is created without internet capability, so the operating system itself refuses outbound traffic from AI-run code. That still isn't an air gap for the whole app: chat still goes to whichever model provider you chose, and the update check, dependency installs you approve, and one-time component downloads can still touch the network. The threat model lists all of it.
Approvals come in two kinds. Ordinary ones are cards inside the app. Higher-risk model actions and certain sensitive operations can require a native Windows confirmation dialog outside the model-controlled interface. Nothing sent from the chat window can mark an action pre-approved, and if the dialog can't be shown the action is refused.

A smaller set of prohibited actions is refused outright in every mode and never offered for approval at all.
There's also an audit trail: a plaintext action log, plus an encrypted, hash-chained forensic log of approvals, denials and sandbox blocks. If a recorded entry is later altered, verification can show it. The docs also state plainly that this cannot prove nothing is missing.
Now the parts you'd find out anyway, so here they are first.
Windows 10/11 x64 only, because the sandbox is built on Windows-specific isolation. There is no macOS, Linux or Windows-on-ARM build.
It is proprietary and closed-source, free for personal non-commercial use, with a separate licence required for commercial use.

Because the source is not public, I have tried to make the externally verifiable parts unusually transparent. The full threat model is public, including trust boundaries, network paths and residual risks, and you can independently monitor its network behaviour.
It's beta software. It has not been independently audited. Prompt injection is documented as not solved, and the app itself ships the line "no sandbox is 100%".
Nyx AI sends no usage analytics, telemetry or crash reports of its own. Automatic update checks are on by default and can be disabled. A check sends the installed version, and the connection necessarily exposes the requesting IP to the update host. Installing from the Microsoft Store also means Microsoft's own platform diagnostics apply under Microsoft's terms, not the app's.
Site and threat model:
https://nyxai.uk

Install is through the Microsoft Store. The website does not host the installer.

Two things I'd genuinely like opinions on.
Where would you draw the line between approvals that deserve a hard OS dialog and ones where an in-app card is enough?
And if you read the threat model, what's missing from it?

The AI wants to run a higher risk action. Nyx AI stops it here.

Nyx AI deliberately invokes a native Windows confirmation before certain higher risk actions can continue.

The model cannot approve this prompt itself. The user has to make the decision.

It is one of several safeguards around agent execution and reduces risk rather than eliminating it . See threat model and legal documents for more information

https://nyxai.uk

https://apps.microsoft.com/store/detail/XPFFRQTJB30WD9

We are building Nyx AI around a straightforward principle: users should be able to choose where their AI runs and retain control over their own data, without being tied to a single model provider or required to send their work through our infrastructure simply to use the software.
Nyx AI is a local first AI workspace for Windows. It does not provide its own AI model. Users can run open source models locally through Ollama, or connect their own accounts with OpenAI, Anthropic, Ollama Cloud or another compatible endpoint. No Nyx AI account is required for local use, and we do not operate a backend that receives users' prompts or project files.

A significant part of our work has focused on what happens when an AI model is allowed to do more than simply generate text. In Nyx AI Lab, the model can work with files, run shell commands and Python, use Git, run builds and tests, and work within a folder selected by the user.
For model run shell and Python processes, Nyx AI's Locked mode uses Windows AppContainer isolation where supported. We also use workspace scoped file controls, command risk checks, approval controls and native Windows confirmations for certain higher risk actions. We do not claim these controls eliminate risk, and our public threat model sets out their limitations and residual risks.

After about a year of building, testing and constantly finding things to improve, Nyx AI is finally out. It is available in 240 markets and 6 languages.

Nyx AI is a local first AI workspace for Windows for chat, coding, documents, previews and automation.
You can run models locally through Ollama or connect OpenAI, Anthropic, Ollama Cloud or your own compatible endpoint. No Nyx AI account is required for local use.
One area I spent a lot of time on was agent safety.

In Nyx AI Lab the model can work with files, run shell commands and Python, use Git, run builds and tests, and preview PDF, DOCX, XLSX and PPTX files.
Locked execution uses Windows AppContainer isolation where supported, alongside workspace file controls, command risk checks, approval controls and native Windows confirmations for certain higher risk actions.

There is also a built in privacy sanitiser designed to detect and redact recognised sensitive information before messages are sent to non local models. It is best effort and cannot guarantee that every sensitive value will be detected.

No sandbox is completely secure and these controls reduce risk rather than eliminate it. The limitations and residual risks are documented in the public threat model, and the legal and technical documents are available inside the app.

Would genuinely appreciate anyone trying it and telling me what you think.

Website
[https://nyxai.uk
Microsoft Store
)Microsoft store nyx ai