OmniNova is a landing page for a proprietary local-first security agent

The repository is a pointer, not a codebase

The first thing to establish is that there is nothing to clone. The repository contains exactly two files, a readme and a Chinese translation of it, and the readme says so directly in a callout: this public repository is a landing page only and no longer contains source code, with installation pointed at a separate download page. The description in the repository metadata calls the project a next generation AI format, while the readme itself names the product OmniNova and describes it as an enterprise security agent with a Rust core. Those two labels do not match, and the primary language field is recorded as unknown, which is consistent with a repository that holds no implementation. The readme also states that the installers are served same-origin from the vendor's own server, which means the binary you run comes from that server rather than from a release asset in the repository you are reading. Anyone evaluating this for a supply chain review will find no commits to review, no build recipe to reproduce, and no tags to pin.

Local-first means the model keys and sessions never leave the machine

The architectural claim is a local-first design, and the visible documentation states the mechanism in a single sentence: the agent runs on the user's own machine, model keys never leave it, and it can drive files, the terminal, the browser and native apps. The capabilities list repeats the point with keys, sessions and skills staying on disk. The provider list is what makes that claim meaningful, and it is broad: OpenAI, Anthropic, Gemini, DeepSeek, Qwen and Ollama, including fully offline local models. The Ollama entry is the important one for a security context, because it means the agent can run against a model that never makes a network call at all, which is the configuration where a local-first architecture stops being a convenience and becomes the point. The readme does not describe how a provider is selected, whether a policy can require the local one, or how telemetry behaves once a hosted provider is chosen. Those are exactly the questions a local-first claim raises, and none of them is answered here.

The tool surface is broad and the safety layer is listed, not described

The tool execution list covers files, shell, browser, Git, PDF and search, and the safety line names an emergency stop, a tool policy and dangerous-command filters. Those three together are the security argument of the product, and the readme does not expand on any of them. There is no description of what the tool policy can deny, whether the emergency stop is a keyboard shortcut or a button in the UI, whether the dangerous-command filters are a blocklist or a pattern matcher, whether a blocked command can be overridden, and what is logged when a filter fires. For an agent whose stated job includes driving a shell and a browser, that is the entire risk surface, and the documentation is one line long. The readme is careful elsewhere, mentioning that macOS may report the app as damaged because Gatekeeper is quarantining an un-notarized build, and directing readers to a macOS install section on the download page to clear the quarantine flag. That is a specific and useful admission. It also tells you the builds are not notarized, which is a fact about the supply chain that any adopter will want to weigh.

Channels are listed eight ways, and the desktop matrix is complete

The distribution story is broad. Channels include Feishu, DingTalk, WeCom, Slack, Discord, Telegram, email and webhooks, which is a mix of enterprise messengers, consumer messengers and plain transport. The readme does not describe what any channel can do beyond being reachable, whether messages from a channel are treated as trusted instructions, or whether a channel can trigger a tool call. The desktop matrix is the more concrete part, and it is given as a table of platform, architecture and format. macOS is covered on both Apple silicon and Intel as a `.dmg`. Windows x64 is offered as a `.exe` and an `.msi`. Linux is covered on x86_64 as a `.deb`, an `.rpm` and an `.AppImage`, and on ARM64 as a `.deb` and an `.rpm`. So the platform coverage is genuinely wide, and the format choices match what each platform expects. What is missing is a version compatibility statement, a minimum operating system version, and any mention of how the product is updated after installation, since there are no releases in the repository to point at.

The licence is proprietary, and that decides the adoption question

The licence section is four sentences and it is the reason this cannot be treated as an open source project. The software is described as proprietary software of OmniNova, with the explicit instruction not to copy, distribute or sublicense it without written permission. The repository metadata also records the licence as unknown, and the readme sits at the top of a repository whose name, novalclaw, differs from the product name, OmniNova. There is no source to audit under any licence, so the practical questions are commercial rather than technical. A team that has to show what runs on its endpoints cannot inspect the binary. A team that has to build around the product cannot rely on a stable extension point, because the readme documents no plugin interface, no API surface and no configuration format. An organisation with a policy against proprietary agents installed with broad tool access, and with keys for several model providers on the same machine, is the profile that should pause here rather than at the feature list.

What a landing page cannot tell you, and what to check before downloading

The honest comparison is between this and an open source agent framework you can read, and the difference in approach is not about features. An open source project gives you the code, the dependency list, the build recipe and the history, so a security review is a code review and a customisation is a patch. OmniNova gives you a binary and a promise. In exchange, you get a packaged desktop experience across five platform and architecture combinations, a curated provider list, a safety layer that is at least named, and eight channels already wired up, none of which you would build in an afternoon. The checks that make sense before downloading are concrete. Confirm the licence terms satisfy what your organisation permits for software with shell, browser and filesystem access. Ask how the dangerous-command filters are configured, whether they can be disabled, and what a triggered filter records. Ask what the emergency stop actually stops and whether it terminates running child processes. And check whether the installer you get is signed and notarised, since the readme already flags that macOS may quarantine the build.

Editorial conclusion

The novalclaw repository is worth reading if you are evaluating OmniNova, because it states the platform matrix, the model providers, the channels and the licence terms plainly and points you at a download page, and that is more than a vendor landing page usually gives you. It is not a project you can adopt as open source, because the readme says the public repository no longer contains source code and that the software is proprietary with copying, distribution and sublicensing all requiring written permission. Before downloading anything, check the licence terms against whatever your organisation requires, since there is nothing here to audit, and note that the repository holds only two files, a readme and a Chinese translation, with no releases and a last push on 2026-09-10, so the only versioned artefacts are the installers served from the vendor's own server.

Frequently asked questions

Official sources

1. Issues
2. README
3. Superagentsys/novalclaw on GitHub