Version 0.115.0 combines Chromium 152 with Node.js 26.7.0
NW.js 0.115.0 lets a desktop page use HTML, CSS, WebGL, browser APIs, Node.js modules, and NW-specific window APIs. Node and Chromium run in the same thread, objects share a heap, and DOM code can call Node modules directly. That makes an existing web application feel close to a desktop application with filesystem and operating-system access. It also removes a boundary that many newer desktop frameworks treat as a security feature, so architecture matters more than the tiny hello-world manifest suggests.
The August 18, 2026 release is NW.js 0.115.0, built on Chromium 152 and Node.js 26.7.0. Downloads cover Windows, Linux, and macOS, with architecture choices listed in the project README. Each platform has a normal build and an SDK build. The normal package leaves out developer tools; the SDK includes DevTools, nwjc, payload, and chromedriver. Teams should decide which artifact belongs in development and which files may be redistributed before automating a release.
Node-enabled frames bypass browser security restrictions
NW.js 0.115.0 retains the documented node-frame model, which gives selected pages access to Node and NW APIs. Those frames can bypass sandboxing and same-origin rules, make cross-origin requests, and reach remote iframe content. A local interface that only renders packaged assets can control that exposure. An application that opens arbitrary websites, user-supplied HTML, or remote scripts needs an explicit separation between trusted Node-enabled pages and normal frames. Treating every page like an ordinary browser tab is unsafe under the documented model.
Open issue 8387 gives that warning a current operational edge. Its reporter reproduced a renderer crash in 0.115.0-sdk on certain third-party sites while using broad node-remote access and extension flags. The issue attributes a specific Chromium extension API failure, but it is still a report rather than a merged fix. It does not show that ordinary packaged pages crash. It does show why a product built around unrestricted web browsing should reproduce its exact navigation and permission model before choosing NW.js.
What happened when we ran it
Our measurement setup used a fresh unprivileged sandbox, where 50 Python packages installed in 20 seconds and used 54 MB at commit 2f18932. The checkout itself was 161.6 MB, with 1,272 files and about 142,819 source lines. The detected build stopped with exit code 1 after 3 seconds. Its log tail showed Python SyntaxWarning messages for identity comparisons with string and integer literals, plus invalid escape sequences in two tools. The tail did not state which warning or other condition caused the nonzero exit.
Pytest exited with code 5 after 5 seconds and printed no tests ran in 0.14s; the summary was 0 passed and 0 failed out of 0. We therefore have no test result for product behavior from this run. Pip-audit reported 7 known vulnerabilities in the installed Python packages. Our scan found a tests directory, no Dockerfile, and 0 CI workflow files. Those are checkout findings, not claims about the security of packaged NW.js binaries.
One repository contains only part of the source
The 1,272-file checkout contains only part of NW.js, according to the README; source and daily development span multiple repositories in the organization. This repository handles issue tracking and the landing page too. That changes how to read our 3-second build failure: it proves the lab's detected command failed here, but it does not prove that the official multi-repository build is broken. A contributor needs the developer build documentation and the other source repositories before treating this as a conventional clone-and-build project.
The checkout had a tests directory, yet pytest collected nothing in our Python 3.12 Debian container. NW.js had no GitHub Actions workflow files here, so this repository alone does not reveal a standard public CI path that matches our environment. Developers evaluating contribution cost should find the actual upstream build automation, reproduce one supported configuration, and identify which repository owns a failing component before estimating maintenance work. The product download is much easier to try than the source is to rebuild.
Native modules and distribution are per-platform work
NW.js 0.115.0 applications ship with the runtime. The packaging guide tells developers to install npm dependencies on every target platform rather than assuming one node_modules tree will travel correctly. Windows and Linux can place app files beside the executable; macOS puts them inside the application bundle and requires signing for normal Gatekeeper behavior. A zipped application payload is supported, though the guide warns that large archives or many files slow startup because NW.js extracts them to a temporary directory.
Native addons add a version constraint. Since NW.js 0.111.3, standard node-gyp can use headers from the NW.js download server, but the rebuild command still names the target runtime version. Switching versions calls for a fresh dependency install according to the official guide. Continuous delivery therefore needs one build lane per supported operating system and architecture, plus binary signing, checksums, installers, and update testing. The README documents SHA-256 files and GPG signatures for verifying stable runtime downloads.
A September 13 push accompanies 914 open issues and pull requests
The repository was pushed on September 13, 2026, two days after the newest open bug report in our query. GitHub listed 41,163 stars and 914 combined open issues and pull requests. Those figures show an old, visible project with current activity and a large support queue. The latest release in the README and official blog is 0.115.0 from August 18, so buyers should follow the project's own download and blog channels.
Current issue activity includes Windows 11 transparent-window regressions reported against 0.115.0 and an open Node ESM import report covering versions 0.102.1 through 0.108.0. Neither issue means every application encounters the behavior, but both involve desktop details that a browser prototype will miss. NW.js remains a practical shortcut when a team values direct DOM-to-Node calls and knows its target platforms. The failed build, empty pytest collection, 7 audit findings, and documented security model make source adoption a deliberate engineering commitment.