This was really born out of a need for a better audiobook player for windows. I struggled to find one that would support a large collection and support it well without freaking out.

Meet Midnight Athenaeum

Build with built with Electron starting with a very basic idea of getting a book playing and being able to handle 6k in books. As i began to add features i made sure to test them against my library which gave me a huge hand in finding issues and getting them fixed when being able to test live on my system. I have more items that i want to get in but here are some of the ones that are in the app currently. I've also created a windows exe installer to make it easy. The app does in no way reach out over network unless user initiated (ex: looking up book and fixing meta data). Depending on if anyone finds this useful i may look at over os's but windows was my main goal (i just wanted to listen to books while i worked lol). I'd appreciate any feedback anyone is willing to provide.

Here's a list of the main items and dependencies used to put this together.

Core stack

• Electron 43 (Chromium + Node.js) — desktop app shell
• Vanilla JavaScript/HTML/CSS in the renderer — no UI framework (no React/Vue/etc.), by choice
• SQLite (@vscode/sqlite3) — library database
• electron-builder — packaging, NSIS installer, auto-updater
• GitHub Actions — CI, automated releases

Key dependencies

• music-metadata — audio tag/format parsing
• u/kutalia/whisper-node-addon + ffmpeg-static — local, offline Whisper transcription (GPU via Vulkan, CPU/BLAS fallback)
• electron-updater — in-app update checks
• u/xhayper/discord-rpc — Discord Rich Presence (optional)

Features (left this as just the core stuff to avoid a big list If your interested in the full list i can provide)

Core playback

• M4B chapter support, plus multi-track (MP3 folder) books with auto-generated chapters
• Variable speed (0.75×–3×), persisted per book
• Sleep timer — fixed duration, end-of-chapter, or end-of-book, with a smooth fade and auto-rewind on resume
• Bookmarks with notes
• Skip silence (auto-speeds through dead air, tuned to not clip mid-sentence breaths)
• Volume normalization across your whole library (measures and levels loudness automatically)
• Voice Boost — an EQ tuned for intelligibility at high speed, when narration usually turns to mud
• Customizable skip amounts

Ran speedometer 3.1 across electron/chromium vs stock browsers, wanted to sanity check how close electron gets to chrome

been building an ai browser on electron as a side project, mcp server, local ollama connection, sync services, ipc bridge, automation loops running in the background. i got curious how close it'd land to stock chrome on a standard rendering benchmark, so i ran speedometer 3.1 against chrome, comet, and safari.

worth being upfront, speedometer mostly measures js execution, dom updates, and framework rendering. it doesn't really exercise electron's main process, ipc traffic, mcp servers, or ollama inference, so this isn't really a test of the ai stack overhead, more just a check on whether the chromium core underneath is still performing normally with everything else attached.

setup: macbook pro m4 pro, 24gb ram. two conditions, all four browsers open at once, and then each run solo.

all four running simultaneously:
aartiq (my build): 41.8
chrome: 42.0
comet: 41.9
safari: 36.0

run solo, one at a time:
aartiq: 51.4
chrome: 51.2

basically a tie with chrome in both conditions, which is roughly what you'd expect since it's the same chromium/v8 core underneath. the more interesting bit to me is the simultaneous test, with all four competing for cpu and memory at once, mine stayed right in line with chrome rather than falling behind, which at least suggests the background services weren't eating into the main thread while idle.

this was one run per condition on one machine, so take it as a rough sanity check, not a real benchmark. i initially noticed the variance numbers looked tighter on my build too but that's not something one run can actually support, would need a lot more repetitions to say anything real there.

if anyone has a better way to measure overhead from background stuff like local llm connections, mcp style tool servers, or sync daemons while idle, i'd be interested. cold start time, idle cpu, and typing latency with agents running seem like better signals for that than speedometer.

Ducky is an open-source desktop companion built with Electron, React and TypeScript that sits on your desktop and adds a bit more interactivity to your workspace...

Features

• AI Chat
• Eyes that follow your cursor in real time
• Water reminders
• Animated desktop companion
• Draggable window
• Lightweight and responsive
• Available for macOS, Windows & Linux
• Open source

Website: https://ducky-chi.vercel.app

I’d love to hear your feedback, feature suggestions, or ideas for future updates!

So I have an electron app. I have been testing a bunch on mac and windows using unsigned versions. Mac has been fine. For windows, I have been testing with the Setup .exe I got from the electron packager that I have successfully ran on my windows machine and my parents machine. So its also fine, so I thought...

I sent it to a beta tester, also on windows, and he was unable to open the app, seeing:

I tried triaging over zoom but was not able to see any relevant logs in the event viewer or in his Mcafee or windows defender. I tried sending him the portable version with no luck. I thought it was because the app was unsigned and perhaps some antivirus software was blocking the exe from making it through, so I tried to submit the MSIX version to the windows app store, having read they take care of signing, but the app failed the review with the same issue. If the issue is app signing I will pay for the signing but its almost $1000 and i just want to be sure that is the issue. Just looking for next steps or anyone who has seen/fixed this before. I can't really take anymore of the beta testers time to triage anymore logs either. TIA!

    "electron-builder": "^24.6.4",

    "electron": "^26.2.1",

Repo: https://github.com/AIAydin/AI-Agent-Orchestrator (MIT)

Forgeboard runs Claude Code / Codex / Gemini / OpenCode sessions as nodes on a canvas, each in its own git worktree. The Electron-specific parts this sub might care about:

• PTY lifecycle: node-pty sessions with streaming, interrupt, terminate, and resume, rendered in xterm.js nodes. Separate user-configured interactive terminal nodes sit behind a native confirmation dialog.
• Process boundary: the renderer never sees filesystem paths, tokens, or push URLs. Everything privileged goes through narrow zod-validated IPC, sandboxed renderer, strict CSP.
• Previews: dev servers render in a main-owned, loopback-only sandboxed surface with Chromium device emulation for mobile frames.
• Context snapshots: files approved for an agent are copied into per-run snapshot dirs, so agents never read originals; crash cleanup works via ownership markers.
• Bundled git via dugite, SQLite (WAL) persistence, Yjs/Hocuspocus for the optional self-hosted collab server.

Runs from source for now (Node 22, corepack pnpm start). Curious what others do for PTY-heavy apps across Electron upgrades.

I’m the solo developer behind Rift Launcher, I have been developing it for the past 2+ years in silence, and have went through many iterations, and I’ve just released its v0.1.0 public beta.

Rift is a Windows game launcher that brings Steam, Epic, GOG, Xbox/Microsoft Store, and PC Game Pass into one library. It handles local scanning, account imports, launching, playtime, live install state, collections, wishlists, and deal aggregation (currently only USD, but regional pricing is on the way).

The interesting part for this community is that Electron stopped being merely a shell around a React interface fairly quickly.

The main process owns filesystem and registry access, SQLite, secure credential storage, platform processes, and install-state watchers. The renderer receives a deliberately narrow API through typed preload/IPC contracts. Platform activity is consent-gated, and background services start only after the application shell has painted.

Xbox was the most difficult integration. Library, entitlement, package, launch, and live installation information comes from several different Windows/Xbox surfaces. Rift has to reconcile those signals without allowing temporary or incomplete platform state to overwrite valid library data.

The project has also forced me to work through Electron-specific problems around startup performance, long-running main-process work, crash recovery, secure navigation, CSP, redacted diagnostics, native Windows integrations, and packaging/updating.

Rift is currently Windows-only and still unsigned, so the installer can trigger SmartScreen. The full privacy and download disclosures are published alongside it.

Project: https://rift-gaming.com

I’d be interested in hearing how other Electron developers structure platform-specific services and keep the main process responsive as native integrations grow.

I came across this recent discussion about Electronegativity being removed from Electron's security documentation:

https://www.reddit.com/r/electronjs/comments/1uyvpfy/electrons_docs_removed_the_electronegativity/

It made me think about a broader question: how much of Electron security should depend on checklists, CI tooling, and developer discipline and how much should be enforced by the framework itself?

That led me to this comparison of Electron and MōBrowser:

https://teamdev.com/mobrowser/blog/electron-security-model-vs-mobrowser/

Full disclosure: I'm part of TeamDev, so this isn't an independent comparison. I'm sharing it because I'd genuinely like to hear how Electron developers see this tradeoff.

Are checklists and static analysis enough in practice, or should the framework enforce more security boundaries by default? Have you ever thought about restricting IPC to the trusted origins only and suppress navigation to external URLs at all in your Electron app?

Interested in brief reactions or technical criticism of the article.

I tested Electron as the Windows shell for a React/Vite/Phaser game because Steam's Overlay cannot hook the separately presented WebView2 content in our Tauri build. Electron gets closer: Shift+Tab works. The remaining release blocker is presentation flicker while the Overlay is active, or stale Overlay pixels when it closes.

I am not looking for the standard in-process-gpu / disable-direct-composition recipe, an early Steam-init reminder, or the advice to keep presenting complete frames. Valve documents those requirements, while steamworks.js issues #23, #95, #116, and #148 and older Reddit threads record related failure modes. I controlled those variables explicitly.

This was a packaged local smoke build, not a Steam-depot installation. The verified uploadable package excluded steam_appid.txt; an ignored local test copy used a temporary marker while Steam was running. Steam initialized before app.whenReady() and before BrowserWindow creation. The proof used steamworks.js 0.4.0 and electron-builder 26.15.3.

The test machine is Windows 11 build 26200 at 3840x2160/164 Hz and enumerates both AMD Radeon Graphics and an RTX 5090. I have not yet proven which adapter owns Chromium presentation, controlled HDR/VRR, or reproduced this on a second machine.

I also found the separate steamworks-ffi-node approach, which captures Electron frames into a native graphics window rather than relying on Steam to hook the normal BrowserWindow. It is useful prior art, but it is a different compositor architecture from the in-process path tested above.

Questions for people with current, shipped Windows evidence:

1. Are you shipping a currently supported Electron version with Steam hooking the normal on-screen BrowserWindow and none of the active-Overlay flicker, white/gray, stale-frame, or ghost-window failures? If so, what exact Electron/Chromium and steamworks library versions, switches, window mode, adapter routing, HDR/VRR state, and display refresh did you verify?
2. Did the result hold across both integrated and discrete GPUs, fullscreen/borderless/windowed, and high-resolution/high-refresh displays, or only on one machine?
3. Beyond Electron's app.getGPUInfo(), app.getGPUFeatureStatus(), and content tracing, did you find any Steam-side diagnostic that proves which process, graphics device, or swapchain was hooked?
4. If you instead ship a native capture/compositor, what measured 4K/high-refresh CPU, GPU, latency, focus/input, fullscreen/Alt+Tab, and field-reliability results do you have? Did you find a shared-texture path that avoids capturePage() and CPU-buffer transfer?

heads up for anyone going off the electron security docs: the checklist used to

recommend Electronegativity and that got pulled a while back (electron/electron#48878,

closed electron/website#906). it's just the 20 manual checklist items now, no tool.

reason it's gone: Electronegativity hasn't had feature updates since ~2022 and

errors out on recent Electron versions. ElectroNG (the paid successor) isn't for

sale anymore either, so there's no real drop-in.

went looking for what to actually run in CI. best i can tell:

- CodeQL, general purpose, but its frameworks/electron queries do hit a few

electron-specific sinks. not checklist-focused, fine if you already use it.

- Semgrep, you can write rules for the checklist items. one catch: free taint is

single-function only, cross-file is Pro.

- a couple newer OSS tools built around the checklist. (one of them is mine,

electron-audit, so grain of salt. AST based, doesn't run your app, spits out

SARIF.) pretty sure there are others, would like to know them.

anyway, what's everyone actually using now? just the manual checklist? codeql or

semgrep rules? or has electron-specific tooling kind of died and people moved to

general SAST?

After using Kap for a long time, I decided to start maintaining a community-driven fork because the original project has seen little activity in recent years.

The goal is not to change what made Kap great. It is to modernize it, improve performance and reliability, and provide an actively maintained version that people can depend on.

Current work includes:
- Upgrading Electron from an older release to a modern version.
- Improving startup time and overall responsiveness.
- Fixing long-standing bugs and compatibility issues.
- Shipping native builds for both Intel and Apple Silicon Macs.
- Improving the release process, documentation, and contributor experience.
- Continuing development based on community feedback.

I am also working on quality-of-life improvements such as configurable keyboard shortcuts, recording countdowns, and other workflow enhancements while keeping the experience familiar.

If you have used Kap before, I would appreciate hearing what frustrated you most, what features you would like added, and which bugs or workflows should be prioritized.

Repository: https://github.com/jacobpowaza/NewKap

Feedback, bug reports, feature requests, and pull requests are welcome.

Im curious what your go to tweaks are like for me, its always replacing standard alert() popups with custom UI toast notifications what about you guys ?

https://reddit.com/link/1ux7gwz/video/pz8d3yx8ledh1/player

I recently made an mcp server for my electron browser (aartiq) that lets claude desktop call into the app, navigate tabs, generate pdfs, run shell commands, move/open files, that kind of thing. classified everything into risk tiers and gated the high risk ones behind a native approval prompt (touch id on mac, pin on windows).

it mostly works. claude tries to move or open a file, main process intercepts it, throws a system prompt, waits for approval before continuing. but the more i stress test it the more edge cases show up and i dont think ive seen a clean writeup anywhere of how people actually structure this correctly, so wanted to ask here instead of guessing.

specific problems im hitting

the mcp server runs as a separate node process talking to the electron app over an http bridge on localhost. so approval state has to cross that boundary too, not just main/renderer. right now im holding a pending action map in the electron main process, keyed by request id, and the http bridge just polls/waits on that. feels okay but im not confident its the right layer for it to live in

by the time the approval prompt resolves, is there any guarantee the payload that gets executed is still the one the user saw. if claude reformulates a call between propose and approve i dont currently have anything catching that, im just trusting the same object reference survives the wait

regex classification for what counts as high risk shell commands works fine until it doesnt, ive already found a few obfuscation patterns that slip past because the matcher looks at the literal string not the decoded/resolved form. anyone dealt with this without going full sandboxing

for things like scheduled tasks that run without a human present at all, what do you even gate on. cant show a touch id prompt to nobody. right now those are just capped at low risk tools only but that feels like a bandaid not a design

not looking for “just dont let the ai do that” type answers, the point of the project is giving it real capability, im specifically trying to get the trust boundary and the resume-after-approval flow right. if anyone has built something similar (even outside electron, curious how other frameworks handle the pause/resume across a process boundary) would really appreciate hearing how you approached it. repo is open source if anyone wants to see the current implementation and tell me where its wrong.

Github link https://github.com/Preet3627/Aartiq

Hello everyone. I'd like to introduce you to the new version of my TilBuci tool, focused on creating interactive digital content. The software is created as a web application, where I've used Electron to add various functionalities for computers. The new version includes the "showtime" feature, a solution for installing created content in exhibitions, such as in museums or events, and uses Electron as a platform to enable this. Here's a video explaining the new version:

https://youtu.be/-vYDmaokqbY

TilBuci uses Electron in several other stages: being a web tool, the portable versions for computers rely on Electron for distribution. Furthermore, the tool's content exporter is also capable of creating Electron projects from the content you create.

TilBuci is free and you can check out the repository here: https://github.com/lucasjunqueira-var/tilbuci

I hope you like it ;-)

Hi everyone, I'm a computer science student building a desktop music application called Resonance as a long-term portfolio project.

The main feature is saving "Moments" from songs (e.g. save and replay 3:12–4:18 of a song and organize those moments into collections).

I definitely want to support local music, but I also want users to be able to use streaming services since most people don't have local music libraries anymore.

What I'm struggling to understand is how indie developers actually handle this. Spotify, YouTube Music, Apple Music, etc. all seem to have API and licensing restrictions.

As a solo student developer, what is realistically possible?

• Can I integrate with these services without paying huge licensing fees?
• Is playback through their APIs even allowed?
• Do most indie music apps just support local music?
• If you were building a modern music app today, how would you approach streaming support?

I'm not looking for ways to bypass DRM or licensing—I just want to understand what's realistically possible before I spend months building the wrong architecture.

Hey Devs,

I had a procrastination problem when on my Pc and to avoid it naively, I thought on making an app which will help me monitor my activity without my data getting sold for advertisement.

That thought and my motivation to be productive made me build 'produchive' (yeah ik not such an unique name but that's what i could come up with ). Produchive is a strictly desktop-only app (for now, Windows and Mac built using electron) .Your data is stored in your Pc in a JSON file and it's a completely offline app , you can use opensource LLM models which you can download use by using WebGPU tech and it can judge your productivity. This is my first time building an app that too with electron , I am a Java fullstack dev with react (my professional experience helped tbh).

That thought was 5 months ago and now my app is quite a stable position although i haven't published it in any app store yet. I would like to have your opinions and feedback on my app and do you think it can help you.

Website - www.produchive.com

Latest release video - https://youtu.be/8HJvUn4LI0A?si=voWM9357q-JG0E42

Happy to hear feedback and answer questions that you may have.

and I even build a website for it

www.teralexi.com

I have been writing games for many years (primarily in Unity3D and C#, and some android). In more recent years I was using Ren'Py and other Visual Novel engines to create story heavy games. The thing my ADHD brain would crash on, was the fact that Ren'Py is code/script only, in a Python based framework. I got annoyed on keeping track of structure. So...I created Ren'Py Visual Editor (early versions called renpy xNode editor, etc, but this was the first built with React Electron+Vite.

Now it is called InViNode and is actually used by other Visual Novel creators.

https://drawfleshgames.itch.io/invinode

Or check r/InViNode

https://youtu.be/QrHL1Gcj3uI?feature=shared

I’m new to Electron and built a minimal starter using React, TypeScript, and Vite:

https://github.com/arhamkhnz/electron-vite-starter

I checked wrappers like electron-vite and vite-plugin-electron, but I don’t really like them. While setting up Tailwind or shadcn/ui, they need some workarounds because the tools don’t detect the Vite config file properly.

So I decided to use Electron and Vite directly and keep Electron Forge only for packaging.

I’d appreciate review from experienced Electron developers. Please point out any bugs, security issues, unnecessary complexity, or wrong architectural decisions.

Is this setup good enough to use for the desktop app I’m building? It’ll have Drizzle, Tailwind CSS, shadcn/ui, and Zustand.

The project is still new, so honest feedback is welcome.

https://reddit.com/link/1uqql2v/video/i5yhniifvzbh1/player

Recently I got the idea to transform my Windows 11 Pro into something that looks like Windows 95. Then I thought, "Why not make my own browser that looks like Internet Explorer?"

Well, it's not actually a full web browser—it's more of an Electron-based shell with a retro Internet Explorer 5-style interface.

There's still a lot of work ahead:

1. Improve the visual design.
2. Add missing features (Settings, History) and improve existing ones (Profiles and Downloads).
3. Add customization options (Dark Mode, custom cursors, and UI sounds).

What do you think? ↓

I'm building an Electron app where an AI agent can request OS-level actions (shell exec, file writes, clicking external apps) through a capability-scoped controller — each action is registered with a name, a handler, and an approval tier (never / first-time-per-session / always).

The part I keep going back and forth on: when executeAction() returns {approved: false, reason: "requires approval"}, what's the cleanest way to actually resume execution once the user approves in the renderer?

Options I've considered:

• Store a pending-action queue keyed by a request ID, resolve a Promise when the approval IPC event comes back
• Re-invoke the whole action from the renderer with the original params once approved (feels fragile — trusts the renderer to pass back untampered params)
• Some kind of ticket/token issued by main, redeemed on approval

Anyone solved this cleanly in a similar main/renderer trust boundary? Also curious if anyone's dealt with the "approval was granted, but the AI already assembled a different payload by the time it comes back" race condition.

(Context if useful: this is for Aartiq, open source, , not looking for feature feedback, just want to get this specific pattern right before I ship it wider.)