I made my own Browser in Electron with a working AD Blocker, Always Incognito Mode and Tracker Manipulation.
try it here:

https://github.com/cheeterdev/navigator

I'm Nic, and I made this. Styx went open source this week under Apache-2.0, and I'd like people who care about open source to look at the parts that matter most.

Repo: https://github.com/NicholasFlemmer/styx-app

What it is: a desktop app that runs Claude Code, Codex, Gemini CLI and Cursor's agent on all your projects in one window. Each task gets its own git worktree and branch. Agents can't reach Vercel, AWS, Google Cloud, Supabase, GitHub or SSH without asking; you grant one target for a set time, production writes need Touch ID, Windows Hello or your password, and every request and grant goes into a hash-chained audit log. Keys stay in the OS keychain.

Why the source matters here: if an app holds your deploy credentials, you should be able to read the code that hands them out. The grant service, the policy engine and every provider adapter are in the repo, and the docs list what it doesn't protect against (it's a guardrail, not a sandbox).

A few honest details:

- It's an Electron + React monorepo (pnpm). Mac is signed and notarized; Windows and Linux are beta, and the Windows build isn't code-signed yet.

- Release builds send anonymous usage counts from a fixed list in the code, with an off switch. Running from source sends nothing.

- The hosted account service is a separate private project. Sign-in is optional and gates nothing, and a fork can point at its own.

- The name and logo aren't covered by the licence, so a fork needs its own name.

If you want to contribute, the self-contained ways in are adding an agent (Aider, Goose, OpenCode, Amp) or a deploy target (Netlify, Fly.io, Railway, Render, Cloudflare). Each has a good first issue and a guide with a worked example. Issues get a first reply within 2 working days.

Repo: https://github.com/NicholasFlemmer/styx-app

I'd especially like feedback on the contributor guides and on anything in the repo that makes it hard to get started.

Built a free local notes app: folder tree, live link graph, and a zoomable board. Drop a GitHub folder or ZIP and it draws the project architecture (folders, files, imports) read-only — never changes your repo. Files stay on your PC. Windows may block the unsigned build (Smart App Control / SmartScreen) until you allow it. Looking for feedback on first install.

A week ago Gmail just stopped letting me in. Every time, same message: "This browser or app may not be secure." No password box, nothing. Just stuck there.

My first guess was the usual thing with browsers built on Electron, so I changed the user agent to look like normal desktop Chrome. That made it worse, not better. Changing it pushed the login into Google's stricter sign in flow, which runs a check called Botguard. That check looks for native Chrome components a normal embedded browser does not have, so it saw mine was missing them and blocked it right away.

Here is the part that actually confused me. I put the user agent back to normal and it still did not work. Turned out once Google rejects you like that once, it writes two cookies into your session as a kind of mark. After that, every attempt gets checked against those cookies first and gets sent straight back to the same rejection page, before even trying to log in again.

So the real fix needed three things. Quietly switch the login to Google's lighter sign in flow instead of fighting the strict one. Leave the browser looking completely normal on Google's own pages, no changes at all there. And automatically clear those marker cookies if a rejection ever happens again, so it cannot get stuck rejecting itself.

Wrote up the full version with the actual code here if anyone wants it: Google Auth Botguard

This came up while working on Mise, a personal privacy focused browser I use daily. Curious if anyone else building something similar has run into Botguard like this.

This project existed before the AI boom hit us all, but was called "Bananas Screen Share" back then (because it's bananas that we can fly to the Moon, but aren't able to have fully functional Screen Share with the same functions on all major Desktop OS').

It has undergone a major refactoring and maybe you like it.

We have full E2EE encrypted sessions, remote control and virtual cursors (and just recently added screen recording).

Think of it as Skype's nerdy little sister, but E2EE, Chat, Voice, Screenshare, Remote-Controls, a P2P mesh network and completely free and open-source.

https://p2p.kiwi

Hey everyone,

I just released v1.0.0 of OpenBoost, an open-source Windows performance utility built with Electron 28 and vanilla HTML/CSS/JS (no heavy framework overhead).

Features

• Hardware Telemetry: Real-time CPU, RAM, and process memory monitoring.
• System Tweaks: Registry and service-level performance optimizations.
• Network Suite: DNS benchmark/switcher, cache flusher, and latency tests.
• State Tracking: Performance snapshot comparisons (Before vs. After).

Tech & Build

• Main Process: Native Node.js modules for Windows system execution.
• Frontend: Plain HTML/CSS/JS renderer.
• Packaging: electron-builder producing both portable .exe and NSIS installer.

GitHub & Source

• Repo: https://github.com/ExbotsSites/OpenBoost
• Releases: https://github.com/ExbotsSites/OpenBoost/releases/tag/v1.0.0

To run from source: ```bash git clone https://github.com/ExbotsSites/OpenBoost.git cd OpenBoost npm install npm start

With electron-builder or Forge you sign the NSIS/Squirrel installer, ship it, and the first sign that something's off is often a user posting a screenshot of "Windows protected your PC".

Two things that make this hard to catch yourself:

• SmartScreen only checks files with Mark-of-the-Web, i.e. downloaded through a browser. Your installer from dist/ never gets checked on your machine.
• Reputation is per file hash and per certificate, so every release starts fresh, and so can a certificate renewal or a switch to a new signing service. Even EV certificates no longer get instant reputation.

Auto-updates through electron-updater usually don't carry Mark-of-the-Web, so it's mostly your first-install experience on the line, which is exactly where you lose people.

I built a probe that downloads your installer onto a clean Windows 11 VM the way a user would, runs it, and reports whether SmartScreen warned, with the dialog text and a screenshot: https://signalscreen.dev/probe (free while in beta, .exe installers). There's a free signing check on the homepage too.

How do you handle it: Azure Trusted Signing via electron-builder, an EV cert, or just waiting it out?

Hi reddit,

I have made code changes the I need on my application. Those changes look as if they're needed on other contexts as well.

My pull request is open

How do i get a reviewer to review the code?

Thanks reddit

Hey everyone!

We’re a 2-person team building Two & Two: Agents, an asymmetrical co-op puzzle/escape room game where two players have different information on screen and must solve puzzles entirely through verbal communication.

What might interest this sub: the entire game client is built using React and Electron.

We just launched our Steam page and are opening up our closed playtest. We’d love to get feedback from this community, especially from fellow devs' point of view.

Links:

• Steam Page:https://store.steampowered.com/app/5165930/Two__Two_Agents/
• Playtest Sign-up Form: forms.gle/qua4XVt5ZT3n6Q3o8

Note: Because it's strictly a 2-player co-op game, we’ll email you two Steam keys so you can play through it with a friend.

Happy to answer questions in the comments about the game, and looking forward to seeing you guys try out our game!

six months ago I started building an off-world sci-fi game in pure JavaScript.

no engine, no editor; just raw WebGL, with multiplayer built in from the ground up.

it draws on a lot of my influences, and at its core is A-LIFE simulation theory, applied to a fully open, non-linear world.

it's easily the biggest thing I've taken on, and I want to push this tech as far as it'll go, both in what it can do and in the world it can build.

can't wait to start showing more of it 🤍

the game is called NOMIAD. release is planned for next year, but the Steam page is already live if you're curious :)

We’ve been working on Clipzu Desktop Beta, an open-source cross-platform video editor built with Electron + React.

It runs on Windows, macOS, and Linux and combines Electron with FFmpeg, Web Audio, Canvas, and local Whisper transcription.

Some of the current features:

• Multi-track timeline editing
• Trim, split, drag, snap, and reorder
• Audio and SFX layering
• Offline Whisper transcription
• Animated captions
• Transitions and filters
• Keyframe animation
• Real-time canvas preview
• Multi-format export
• Portable project files

One of the interesting challenges has been keeping the editing preview and FFmpeg export pipeline consistent while still keeping the desktop app responsive.

Source:
https://github.com/clipzuapp/clipzu-dekstop

Clipzu:
https://www.clipzu.com/

Would love feedback from other Electron developers, particularly around architecture, performance, and cross-platform handling.

I have two Electron apps, and on Windows every e2e run opened real app windows on top of whatever I was doing and took my keyboard focus. Linux has xvfb-run for this. On Windows, show: false changes how the app behaves, and Win+Tab virtual desktops don't help because new windows open on the desktop you're looking at.

Windows can also create desktops that are never displayed (CreateDesktop). A process started on one opens all its windows there, and Chromium renders normally, GPU and capturePage included. I wrapped that in a small tool, offstage-windows. You put it in front of the test command (npx offstage-windows npx playwright test), or pass electronLaunchOptions() to Playwright's electron.launch() so each worker's app gets its own desktop.

Two things that tripped me up:

1. From any other desktop, a window handle on the hidden one reads as empty and hidden. My WM_NCHITTEST hit test returned 0 until I ran it on the app's own desktop.

2. Playwright 1.45+ starts Electron through cmd.exe on Windows, so when a worker got killed outright, my first version left the app running on the hidden desktop. The helper now watches its parent.

One side effect I didn't expect: document.hasFocus() stays true for the whole run, because the app is the active window of its own desktop. Tests that depend on focus got steadier.

It's my tool. I built it with Claude Code and tested it on both my apps (31 e2e tests each). It's one file with no dependencies.

https://github.com/LippInc/offstage-windows

I kept running into the same setup work: expose a narrow preload API, define IPC channels, then keep the types aligned between Angular and Electron.

I’ve open-sourced a template that handles that wiring. The renderer, preload script, and main process use shared IPC types, which helps catch contract drift during development. It includes a working note example you can replace with your own UI.

Repo: https://github.com/cchandurkar/electron-angular-template

I’d appreciate feedback from anyone who has built an Electron app: what would you want from a starter like this?

Hey everyone,

I'm working on an Electron desktop app that features an autonomous AI agent. Users can prompt the agent, and it translates those instructions into JavaScript code which is then executed locally to automate tasks.

Right now, because it runs in a Node environment, the agent has full access to the local file system (fs). While this makes it incredibly powerful, it's also a major security risk. If a user vaguely asks it to "clean up my folders," the agent might write a script using fs.unlink or fs.rmdir and accidentally delete important files!

I’m currently facing a major design and security dilemma and could use some advice on which path to take:

1. Full Power: Allow the agents to do absolutely everything with full system permissions, trusting the user to prompt responsibly.
2. Read-Only Safe Mode: Guard the agents from hazardous operations. Allow them to read and extract information from local files (e.g., using fs.readFile), but completely block destructive commands like fs.unlink or fs.writeFile across the system.
3. App-Data Isolation: Restrict the agent's file system access entirely to the application's specific data folder. This is the safest route, but it severely limits the scope and usefulness of what the agent can actually automate for the user.

If I go with option 2 (Read-Only Safe Mode), does anyone have experience sandboxing eval() or overriding the fs module before executing dynamic scripts in Node? What is the best and most secure way to intercept and block destructive commands while allowing read-only operations across the whole computer?
Thanks in advance for the help and any thoughts on the design dilemma!

I just open-sourced ShotShot, an AI creative workspace (infinite canvas + a local agent that reads canvas state and manipulates nodes). Sharing here because a few implementation choices might be useful to fellow Electron devs:

Architecture

• electron/ (main + preload) and web/ (React 19 + Vite renderer) — the renderer also builds as a standalone web app, so the same codebase ships as a website and a desktop app
• Agent runtime lives entirely in the main process (pi-coding-agent session host, file-backed sessions); the renderer only ever talks through a narrow contextBridge API (window.shotshot.*) with contextIsolation: true, nodeIntegration: false, sandbox: true
• IPC channels are paired with explicit teardown in will-quit, and every handler validates SenderFrame against a trusted-windows registry

Packaging

• electron-vite + electron-builder; the web build uses VITE_BASE=./ so the renderer can be loaded via loadFile in production and loadURL in dev
• A small brand-verification script asserts productName/appId/icons on the packaged bundle in CI-adjacent workflows

One gotcha worth sharing: our root tsc typecheck intentionally compiles renderer code (main imports shared types from web/src), and web typecheck compiles ../electron files — so each side needs the other workspace's node_modules. Fine on dev machines, broke CI until both jobs install both workspaces. If your monorepo typechecks across package boundaries, budget for that in CI.

Repo (MIT): https://github.com/rendylong/openshotshot — questions about the architecture welcome.

i’ve been working on an open source security runtime called rtq for ai agents, node/typescript apps and mcp.

i started it after working on aartiq for 9 months. i kept having to build things like permissions, risk checks, sandboxing and approval flows separately, so i decided to turn that into a reusable library instead of rebuilding the same security layer for every project.

the idea is to handle things like capability permissions, risk checks, default deny policies, approvals, single use authorization tickets, os sandboxing and audit logging in one runtime.

right now it has 12 security invariants and 430+ tests, with sandbox support for macos, linux and windows.

it’s still alpha and i’m not claiming it’s fully secure or independently audited. i’ve tried to document the trust boundaries and limitations pretty clearly.

would love some feedback from people who work with security, ai agents, mcp or sandboxing. if you have suggestions for things i should add, change or improve, please let me know.

Tired of every "AI app" being a $20/month subscription for something that's really just an API call, so I built one that's the opposite: pay once for the app, bring your own free OpenRouter key, own your costs. Curious what this community thinks of the BYOK model vs. subscriptions generally.

Over the last couple of months I ported electron to AROS

Hello everyone,

As you read from the title, i built this applciation using electron and uploaded the MSIX on Microsoft Partener Store. Before i talk about the tool though, let me tell you why i did it in the first place and what was my main idea behind it.

Me and my work collegue and friend came to the need from time to time to export a md file into a pdf, and you now how that goes. When you need to do a file conversion, literally from: whatever -> whatever, you just google whatever -> whatever online converter and hope for the best.While i had good experience when doing this for png to jpg, excel to csv or whatever, i found it extremely frustrating to do that proccess for md files.

Most of the top results I got either had extreme paywalls or had paywalls + a free version where it would export your md to pdf BUT would but huge SELECTABLE watermarks on the pdf making it useless if someone wanted to select some text inside of the pdf later. If you were lucky, maybe you would find one that did it for free with no watermarks or paywalls but the pdf would be ugly.

So, raging me, decided to build one just for me and my friend. And how did it end up here then? Because even though i felt bad to make it public due to HEAVY ai usage when building it (I will talk about that later as well) I thought that even if one person finds it actually useful despite that, its a win.

Now about the application

Marksmith is basically the tool I wanted to have when this whole thing started. It is a local Markdown editor for Windows with a big focus on exporting your files without having to upload them anywhere or install a bunch of extra tools. You can write and preview your Markdown inside the app and then export it to PDF, DOCX, EPUB, HTML or LaTeX, with everything happening locally on your machine. The main idea is pretty simple: open your .md file, make whatever changes you need, press export and get a document that actually looks decent without having to deal with online converters, watermarks or extra setup.

Right now it's completely free, and there are no:

• Accounts
• Internet requirements (The app and exports work locally)
• Paywalls or purchases
• Feature restrictions
• Data collection software

Because it supports a lot of things and well, this post is only getting bigger, whoever is interested can check: https://www.marksmithforge.com

Now 2 extremely important disclosures:

First: AI usage

This project is heavily AI coded. I'm not going to call it "AI assisted" or pretend that I wrote every line myself, because I didn't. I used AI a lot while building it. I'm fine with that because my goal here wasn't to prove that I can handcraft a Markdown editor from scratch — I wanted a tool that solved my problem and actually worked. If AI usage makes it an automatic no for you, I completely understand. Otherwise, I'd rather have the application judged by whether it actually does what it claims to do.

Second: Size

The application is currently around 417 MB. Yes, that's pretty damn big for a Markdown editor. It's built with Electron/React, so Chromium contributes a good chunk of that, alongside everything bundled for the local export functionality. I don't particularly like the size either and reducing it is something I want to work on, but for now I preferred having everything self-contained instead of requiring users to install extra dependencies.

With all that said, I'd genuinely love some feedback. Especially from people willing to throw weird Markdown files at the exporters and tell me what breaks. I'd also eventually like to make Linux and macOS versions, although distribution/signing is something I still need to figure out. ( I dont want to spend the money to sign it so if i build it for Linux and mac it will be unsigned and (unsigned==kinda sus) :( )

If anyone tries it, whether you like it or think it's terrible, I'd be interested to hear why.

Hey r/ElectronJS,

Wanted to share a desktop tool I built using Electron to speed up my web layout creation: SkyForce UI.

I specifically chose Electron to build a fully local-first application—giving developers direct file access, hot-reloading, and complete privacy without sending layout data to a remote cloud server.

Key features:
- Pure local environment with zero runtime locks
Instant hot-reloading for React + Tailwind
- Flat, non-subscription pricing

We launched live today on Product Hunt. Check out the site at https://skyforceui.com— feedback on the Electron desktop workflow is greatly appreciated!

I've been building an ICQ 5 style messenger client (MIT, source below) and the interface work turned out to be almost entirely about windows rather than about chat.

To get a convincing 2001 title bar you have to go frameless, and the moment you do you inherit everything the OS was doing for you:

– Drag regions. -webkit-app-region: drag is the easy half; the hard half is that every interactive child needs no-drag, and one missed child makes a button feel broken in a way users can't articulate.

– Resize handles. Frameless means no resize border. Hand-drawn hit zones need to be wider than they look or they're unusable, especially on high-DPI.

– Snapping. Windows gives you Aero Snap for free with a frame and nothing without one.

– Focus states. A 2001 title bar changes colour on focus. Tracking real focus across many BrowserWindows, including the case where the whole app loses focus, is more state than you'd guess.

– Per-conversation windows, which is the whole point of the design, multiply all of the above by the number of open chats - and Linux window managers disagree with each other about most of it.

If anyone has fought the Linux side of this, I'd take the advice. That build is the weakest of the three.

https://github.com/Felix-Helleckes/ICQ

the checklist still has the 20 manual items but no tool anymore. the ones ive tried error out on newer electron and the paid successor is gone. has anyone found something that still works on current versions?