CodeSandbox desktop app on a Mac: one window for each project

Searching for a CodeSandbox desktop app usually follows a specific irritation. The editor is a real editor now, with a terminal, a preview and a devtools panel, and it is sitting in a browser tab next to a mail client and eleven other pages. The obvious fix would be an installer. That installer does not exist, and the two routes that once came closest have both been retired. What remains is worth setting up properly, because the browser is not going away and a tab is the worst possible container for a full screen editor.

The desktop app exists, as an archived experiment

There is an official repository called codesandbox-desktop under the CodeSandbox organisation on GitHub. Opening it shows the state of the project before anything else does.

This repository was archived by the owner on Mar 12, 2024. It is now read-only. Source: github.com

The README describes an Electron wrapper that runs CodeSandbox as a standalone application, and states plainly that the project is a work in progress. The listed setup is a git clone, Node.js, then yarn install and yarn start. There are 41 commits, three contributors and no releases published, which is the detail that settles the question: there was never a downloadable build to install, only source to compile.

Read against its own description, the repository is exactly what it says it is. Someone at CodeSandbox tried wrapping the web editor in Electron, the experiment did not become a product, and the code was frozen. Archiving it was an honest signal rather than a failure. The relevant conclusion for anyone on a Mac today is narrow but firm: cloning an archived Electron wrapper from 2024 is not a maintenance plan. It would run against a platform that has changed underneath it, with no one shipping fixes when it breaks.

That also explains why third party catalogue sites appear high in the results for this search. They are listing a wrapper of their own making, not a CodeSandbox download, and the page titles do not always make the difference obvious.

The VS Code route closed too

The other historical answer was to stop treating CodeSandbox as a website and pull it into a local editor instead. There was an official extension for that, and its marketplace listing now carries a heading rather than a feature list.

This extension has been deprecated and will stop working on July 15th, 2026. Source: marketplace.visualstudio.com

The same page states that creating new branches from the extension is no longer available because the functionality has been disabled on the server, and it points existing users at codesandbox.io instead. The listing records 206,515 installs, which is a useful measure of how many workflows that retirement touched.

The extension was not a thin viewer either. Its feature list covered branches, tasks, live collaboration across devices, and shared live terminals, with teammates able to join from the online editor or the iOS app. All of that capability moved to the web editor rather than disappearing, which is the point. CodeSandbox consolidated on one surface.

So the decision facing a Mac user in 2026 is simpler than the search results suggest. There is no supported native client. There is a web application that has absorbed every feature the clients used to expose. The only remaining choice is what kind of window it runs in.

What moved into the browser when the clients went away

It is worth looking at what the retired extension actually did, because that list is now the browser's job and it explains why the tab has become heavy enough to complain about.

The extension exposed branches, letting a branch be created or switched from the command palette. It exposed tasks, so that a project's setup commands ran automatically. It exposed live collaboration, with several people on the same branch, including people joining from the online editor or the iOS app. It exposed live terminals, visible to everyone collaborating on the same branch. Its documentation also pointed at interactive READMEs, integrated devtools and previews.

None of that is a light page. A branch switcher, a shared terminal, a live preview and a devtools panel in one document is an application by any reasonable definition, and it is now running inside a container designed for reading articles.

Wikipedia's own summary of the platform's limitations is blunt about the trade being made: slower performance on larger tasks than a native IDE, performance and storage limits on the free tier, some features behind a paid subscription, and limited offline capability. Those are properties of a cloud editor, not of a tab, and no window changes any of them. Knowing which complaints a window can fix is the point of separating the two lists.

A cloud editor is a window problem, not an offline problem

It is worth being precise about what a desktop app for this product could and could not deliver, because the expectation usually imported from other tools does not apply.

CodeSandbox is a cloud development platform. Wikipedia's infobox lists its platform as a web application, its licence as proprietary and its model as freemium, and the product's own positioning is isolated cloud environments that spin up on demand. The code runs on a remote machine. No wrapper changes that. A native client would not have given offline editing, because there is nothing local to edit.

What a native client would have given is everything else that an application gets on macOS. A fixed Dock position. A Cmd+Tab entry. A Spotlight name. A window that is not one of thirty tabs. A session that survives a browser restart triggered by something unrelated, such as an extension update or a crash in a different tab.

That list is not a small consolation prize. For an editor it is most of the value, because an editor is used in long sessions and reached many times a day. The thing a browser tab cannot provide is a fixed place to return to. A tab's position drifts every time the strip changes, so the muscle memory that makes an editor fast never forms.

A browser also keeps a set of key combinations for itself. Cmd+T opens a tab, Cmd+W closes one, Cmd+L jumps to the address bar and Cmd+N opens a window. Those belong to the browser chrome, not to the page, which means an in browser editor has to route around them. A window created without a tab strip and without an address bar has fewer of those reservations in the way, and Apple's documentation for Safari web apps confirms the navigation controls can be turned off entirely in the window's settings.

One window per project, or one per account

Two separate reasons push towards more than one window, and they are worth keeping apart because they have different answers.

The first is identity. CodeSandbox signs in through an account, and plenty of developers hold two: a personal one attached to a personal GitHub account, and one inside a client's or employer's organisation. A browser stores one session per site per profile, so two accounts in one profile means signing out and in. That is not a small annoyance for an editor, because it is the point at which a commit lands under the wrong name.

The second is separation of work in progress. A cloud editor holds state per project: which files are open, where the terminal is, what the preview is pointed at. Two projects in two tabs of the same browser share cookies, storage and often the same signed in identity, so the only thing separating them is which tab has focus. Two windows that are separate applications keep their own sessions and their own icons, which means a client project and a personal side project can be open at once without either one being a click away from the other's terminal.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

What a purpose built window covers, including the per app browser profile that makes that separation possible, is set out on the Features page.

The routes, side by side

Route	Setup	Dock and Cmd+Tab	Session per window	Maintained	Suits
Browser tab	None	No	No	Yes	Occasional use
Pinned tab	One click	No	No	Yes	One account, one project
Archived Electron repository	Clone, Node, yarn, build	Yes	Yes	No, read only since March 2024	Nothing in production
VS Code extension	Retired	N/A	N/A	No, stopped July 2026	Nothing
Safari, Add to Dock	Two clicks	Yes	Yes	Yes	One account
Chrome, install page as app	Three clicks	Yes	Follows the Chrome profile	Yes	Already on Chrome
Site to app tool	Pick the URL once	Yes	Yes, per app	Yes	Two accounts or several projects

Chrome's own route is the three dot menu, then Cast, save, and share, then Install page as app.

A web app is an app built for the web that you can access on any device. Source: support.google.com

The caveat is the profile. A window built from a Chrome profile signs in as whatever account that profile holds and keeps sharing that session, so two identities means two Chrome profiles before anything else happens.

What to check in the first week

An editor exercises more of the browser than a reading site does, so a few checks are worth running deliberately rather than discovering later.

Sign in survival comes first. Restart the Mac, then install a macOS update, and confirm the window opens signed in rather than at a login screen.

Second, the GitHub authorisation flow. Connecting a repository opens a provider window and then returns. Run that once inside the new window and watch the return complete, because a blocked popup is the most common reason a new window looks broken on day one.

Third, the keyboard. Work through the shortcuts used most in the editor and note any that the surrounding window still claims. Hiding the navigation controls removes several of them.

Fourth, the preview. A dev server preview often opens in a second window, and it is worth knowing whether that lands inside the app or bounces out to the default browser, since the answer decides whether the workflow stays in one place.

Fifth, the clipboard in both directions, between the editor and a local terminal or a local editor. A week is the right observation period because sessions can expire on a cycle longer than a day, and anything that survives a full week is stable enough to build a habit on.

The common services people set up this way are listed on the Supported services page.

What to change first

Stop looking for an installer, because the archived repository and the retired extension are both dead ends, and give the web editor a window with a fixed Dock position and no address bar instead. If a personal account and an organisation account are both in play, create one permanently signed in Kagemusha window for each so neither is ever a sign out away.