Sandboxie GitHub and the Project's Open-Source Home

Sandboxie lives on GitHub. Its source code, its compiled installers, its release notes, its bug tracker and a good part of its documentation all sit in a single public repository, and anyone who wants to understand where the software comes from, what has changed between versions or how to report a fault will end up there sooner or later. This guide treats the Sandboxie GitHub repository as what it really is: the working home of the project rather than a mere download mirror. It explains how the code arrived there, what the repository holds, how to tell a stable release from a test build, how to read a changelog with some care, and how ordinary users can contribute without writing a line of C.

Nothing here requires a GitHub account to follow. Browsing releases, reading issues and downloading files are open to everyone. An account becomes necessary only when you want to file a report, join a discussion or propose a change, and even then the process is lighter than many people expect.

From Shareware to an Open Repository

The project did not begin as open-source software. Ronen Tzur released the first version on 26 June 2004 as a means of sandboxing Internet Explorer, and over the following years it grew to cover other browsers and, eventually, almost any Windows program. Version 4.02 brought full support for 64-bit Windows. For most of its early life Sandboxie was shareware: the free version carried limits, such as running only one sandbox at a time, and nag screens appeared once the trial period had passed.

Ownership then changed hands twice. Invincea announced its acquisition in December 2013, and Tzur left early in 2014. In February 2017 Sophos announced that it was acquiring Invincea, and Sandboxie came with it. In September 2019 Sophos made the program freeware with version 5.31.4 and announced an intention to release the source. That promise was kept on 8 April 2020, when Sophos published the code under the GPL 3.0 licence as a source-only release numbered 5.40 and stepped away from the project.

The decisive moment came the following day. David Xanatos forked the released code and began maintaining it publicly on GitHub, in the repository named sandboxie-plus/Sandboxie. From that fork came the two editions people use now: Sandboxie Plus, with a modern interface and every new feature, and Sandboxie Classic, which keeps the original interface. Because both editions are built from the same tree, the Sandboxie GitHub repository is not one source among several; it is the source.

What the move changed in practice

Under its corporate owners, development happened behind closed doors and users saw only finished builds. On GitHub, by contrast, every release is tagged in public, every change can be traced to a commit, and the conversation about bugs happens in the open. That transparency matters for a program of this kind. Sandboxie installs a kernel driver and intercepts system calls, so being able to inspect what it does, or at least to see that others can, is a reasonable thing to want from software granted that degree of trust.

What the Sandboxie GitHub Repository Contains

A first visit to the repository can feel disorienting, because it holds several distinct programs that only make sense together. The easiest way to understand the layout is to separate the shared core from the two user interfaces and from the material that surrounds them.

The shared core

Both editions rely on the same three components, and these form the technical heart of the codebase, written in C and C++:

• SbieDrv.sys, the kernel driver. It creates sandboxed processes with heavily restricted tokens and enforces the rules that govern which system calls may succeed.
• SbieSvc.exe, the service. It carries out privileged helper tasks on behalf of sandboxed programs and handles injection of the DLL.
• SbieDll.dll, the library injected into every sandboxed process. It virtualises the file system and registry, merging the contents of the sandbox with the real system so that the program sees a coherent view.

Because these components are identical across editions, a security fix made to the driver or the DLL reaches Plus and Classic users alike. That is why the two editions are released together, under twin version numbers.

SandMan and the Classic interface

The Plus edition's front end is SandMan, a Qt-based manager that offers a dark mode, an optional Windows 11-style theme and a Vintage View mode that reproduces the look of the old Sandboxie Control. The Classic edition keeps the legacy MFC interface, Sandboxie Control, whose executable is SbieCtrl.exe. Classic is no longer developed as an interface, but it still receives the same security and compatibility fixes through the shared core. New features reach Classic users only through manual editing of the main configuration file, and only where the feature supports that.

Installer scripts and documentation

Alongside the programs, the repository holds the material needed to package them into installers and a body of documentation describing settings, command-line options and behaviour. Translation files for the Plus interface live here as well; the project currently offers its interface in more than eighteen languages.

Releases Versus Source Code Archives

The single most common misunderstanding about the Sandboxie GitHub page concerns what you actually download. GitHub offers two quite different kinds of file, and confusing them leads to frustration.

Each tagged release carries a set of attached assets. For a recent release there are six: the compiled installers and their accompanying files, with SHA-256 checksums published so that you can verify what you have downloaded. The installer names follow a predictable pattern:

Sandboxie-Plus-x64-v1.18.8.exe
Sandboxie-Plus-ARM64-v1.18.8.exe
Sandboxie-Classic-x64-v5.73.8.exe

These are the files most people want. The Plus installer is roughly 24 MB; the Classic installer is around 3 MB.

GitHub also automatically attaches "Source code (zip)" and "Source code (tar.gz)" archives to every release, and offers an archive of the master branch from the repository's main page. These contain source code only. Opening one will not produce anything you can install; turning that code into a working program requires Visual Studio, Qt and a fair amount of patience. The download offered on this website is exactly that kind of file: the GitHub archive of the master branch, intended for people who want to read or build the code. Anyone who simply wants to run Sandboxie should fetch a compiled installer from the project's GitHub releases page instead.

Latest and Pre-release tags

GitHub labels releases in two ways that matter here. The release marked Latest is the current stable build; at the time of writing that is Plus 1.18.8, paired with Classic 5.73.8, released on 17 October 2026. A release marked Pre-release is a test build. The current example is 1.19.0, paired with 5.74.0, published on 23 October 2026 after a broad hardening effort that followed an AI-assisted audit of the codebase. Its notes describe fixes for buffer overflows, out-of-bounds reads, memory disclosure, leaks and race conditions, together with stricter validation of configuration. The developer asked users to test it and to fall back to 1.18.8 if they met regressions.

The distinction is not merely cosmetic. Pre-releases are sometimes unsigned, which can cause antivirus products to raise warnings, and they exist precisely so that problems surface before a build is promoted to stable. If you depend on Sandboxie for daily work, stay on the Latest tag. If you enjoy testing and can tolerate occasional breakage, pre-releases are where your feedback is most useful.

Why there are two version numbers

Every release carries a Plus number and a Classic number, and they describe the same code. Plus 1.18.8 and Classic 5.73.8 are one release. Download portals frequently display only one of the two, so a site listing "5.73.8" is not offering something older or different from a site listing "1.18.8". Reading the release title on GitHub, where both numbers appear, removes the ambiguity.

Reading Release Notes and the Changelog

Release notes on the repository are written for people who already use the program, which makes them dense but informative. A little practice turns them from a wall of text into a useful briefing. The notes for the 2026 releases illustrate the kinds of entry you will meet.

• Security fixes are the entries to look for first. Release 1.17.3 in March 2026 fixed CVE-2026-32603, a local denial-of-service issue, together with a bypass of the EditAdminOnly protection. Release 1.18.8 fixed an out-of-bounds read in the GUI proxy.
• New settings usually appear with their exact names, which is helpful when you later edit the configuration file. Release 1.17.4 introduced automatic detection of Electron applications, which can be disabled with UseElectronDetection=n, and added a BlockLocalLoop=y option.
• Compatibility fixes often name specific software. Release 1.18.0 delivered reliable Chromium profile sharing for Chrome, Edge and Brave; 1.18.3 addressed Firefox 154 in Standard Isolation boxes; 1.18.5 fixed Chromium and Electron crashes in App Compartment boxes.
• Interface changes describe what you will see differently. Release 1.17.6 added "(Administrator)" to the window title when SandMan runs with administrator rights, and 1.18.1 brought validation and auto-completion to the INI editor.

Almost every set of notes ends with the same practical advice: if an update fails, uninstall the previous version while keeping the configuration file, then install the new build. That sentence is worth remembering, because it resolves the majority of upgrade problems reported in the tracker.

A sensible habit is to read the notes for every release between the version you have and the one you are moving to, not just the newest. Settings introduced along the way may change behaviour you rely on, and a fix you were waiting for may already have landed several versions earlier.

Issues, Discussions and Writing a Good Bug Report

The issue tracker is where faults are recorded and fixed. It is busy: the project shows hundreds of open issues at any given moment, which reflects the sheer range of Windows software people try to sandbox rather than neglect. Discussions, where enabled, are better suited to questions, configuration advice and ideas that are not yet concrete enough to be bugs.

Before opening anything new, search. The problem you have met with a particular browser or game may already be documented, perhaps with a workaround in the comments. Adding a short, factual confirmation to an existing issue is more helpful than opening a duplicate.

What a useful report contains

Developers can only fix what they can reproduce. A report that lets them reproduce the problem on the first attempt is worth far more than a long account of frustration. The following details make the difference:

• The exact Sandboxie version, with both numbers if you know them, and whether you use Plus or Classic.
• Your Windows edition, version and architecture, whether x64 or ARM64, and whether you run an Insider build, since Windows updates and Insider builds can temporarily break the driver.
• The program that misbehaves and its version, because a fix for one release of a browser may not apply to the next.
• The box type in use: Standard Isolation, Security Hardened, Privacy Enhanced or App Compartment. Behaviour differs sharply between them.
• The relevant section of the configuration file for the affected box, with any personal paths removed.
• Any SBIE message codes shown by SandMan, quoted exactly. Release 1.17.4, for instance, made message SBIE2189 suggest a SpecialImage=chrome,program.exe setting; such codes point developers straight to the relevant code path.
• Whether the problem persists in a freshly created box with default settings. If it does not, a custom setting is the likely cause.

Write plainly, describe what you expected and what actually happened, and keep one problem per issue. If the fault appeared after an upgrade, say which version last worked. That single detail often narrows the search to a handful of commits.

Contributing Without and With Code

Open source invites participation, and this project offers several ways in, not all of which involve programming.

Translations

The Plus interface is translated into more than eighteen languages, and those translations are maintained largely by volunteers. Release 1.18.6 in October 2026 added Persian, an example of how a single contributor can bring the program to a new group of users. Translation work suits people who know the software well and write their own language carefully. Keeping an existing translation current as new settings appear is just as valuable as starting a new one.

Compatibility settings for particular programs

Much of the practical value of Sandboxie lies in knowing which settings a particular application needs in order to run properly inside a box. Users who discover a working configuration for a troublesome program can share it through an issue or discussion, explaining which rules were required and why. Such contributions help the maintainers decide whether the program warrants built-in handling, much as Chromium-based browsers and Electron applications received dedicated treatment in the 2026 releases.

Code contributions

For developers, the route is the usual one on GitHub: fork the repository, make a focused change on a branch, and open a pull request that explains what it does and how it was tested. Changes to the driver or DLL deserve particular care, because they affect the security boundary for every user. Small, well-described pull requests are easier to review than large ones, and linking to the issue a change addresses gives the reviewer useful context.

Licences and Building From Source

The two editions are licensed differently, and the difference matters if you intend to redistribute, modify or use the software at work.

Sandboxie Classic is licensed under GPL-3.0-or-later, continuing the terms under which Sophos released the original code. You may study, modify and redistribute it, provided you honour the conditions of that licence, including making source available for any modified version you distribute.

Sandboxie Plus uses a custom, open-core licence. Its source is public on the same repository, but the licence is not the GPL. Plus is free for personal, non-commercial use. Commercial or educational use of Plus requires a Business certificate, and certain features, among them Privacy Enhanced, Security Hardened and App Compartment boxes, require a supporter certificate. Public code, in other words, does not by itself mean unrestricted use, and anyone deploying Plus in an organisation should read the licence before doing so.

Building at a high level

Building Sandboxie yourself is a project for experienced Windows developers rather than a convenient way to obtain the program. The broad outline is as follows. You obtain the source, either by cloning the repository or by unpacking the master-branch archive. You install Visual Studio with the C and C++ workloads, and the Qt toolchain needed for SandMan; the 1.16 series moved the project to a modern compiler and Qt toolchain, so older guides may describe outdated versions. You then build the core components and the interface, and package the result.

One obstacle deserves emphasis. A self-built kernel driver will not carry the project's signature, and 64-bit Windows expects kernel drivers to be signed. Testing a home-built driver therefore typically involves a dedicated test machine or virtual machine configured for driver testing, never your everyday system. This is one reason the official signed installers on the releases page remain the right choice for nearly everyone.

Frequently Asked Questions

Conclusion

The repository tells the whole story of the project in one place. Its history explains why there are two editions and two version numbers; its structure shows how a shared driver, service and DLL sit beneath two quite different interfaces; and its release pages make clear the difference between an installer you can run and an archive of source code you can study. Reading release notes with attention, distinguishing the Latest tag from a pre-release and verifying checksums are small habits, but together they make using the software calmer and safer.

The repository is also the place where users can give something back. A precise bug report, a carefully maintained translation or a well-documented configuration for a stubborn application all improve the program for everyone who comes after. Whether you visit to download a signed installer, to read the code that will run with kernel privileges on your machine, or to help fix a fault you have found, the Sandboxie GitHub project rewards the time spent learning how it works.