You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows, Freebuff Desktop opens its window successfully but the UI never finishes loading — it is stuck on the loading screen indefinitely. This has reproduced identically across three consecutive releases (0.0.73, 0.0.74, 0.0.75), and another user reported the same class of failure starting at 0.0.71 (#1093, "the Freebuff shell is gone; shutting down"). I've done fairly deep isolation testing (details below) that rules out GPU, antivirus, and a broken Electron/install, and narrows the likely fault to the renderer bootstrap path (JS bundle / preload / IPC) rather than the backend.
Environment
OS: Windows (please run winver and fill in your exact build, e.g. Windows 11 23H2)
Orchestrator/Bun is healthy: log shows freebuff-desktop orchestrator listening on http://127.0.0.1:<port> with no errors.
Backend HTTP serves the UI correctly: Invoke-WebRequest http://127.0.0.1:<port>/ returns 200 OK with valid index.html content.
Electron itself is not broken on this machine: a minimal standalone Electron app (BrowserWindow loading https://example.com) launches and renders fine.
Not a GPU issue: reproduced identically with --disable-gpu --disable-gpu-compositing --disable-gpu-sandbox --disable-gpu-rasterization.
Not blocked by Windows Defender: checked Microsoft-Windows-Windows Defender/Operational event log — no entries referencing Freebuff, Electron, or Bun processes.
Not an installation/corruption issue: resources\app.asar, resources\orchestrator\, resources\bun\, and resources\orchestrator\ui\index.html are all present and intact.
Not version-specific: identical symptom across 0.0.73, 0.0.74, and 0.0.75.
Where I believe the bug is
Since the backend (/) returns 200 and Electron itself works standalone, the failure looks like it's isolated to one of:
The renderer's JS bundle failing to load/execute after index.html is served.
preload.cjs throwing or failing silently, breaking the IPC bridge.
Renderer ↔ main process IPC calls (auth/session/config) hanging indefinitely, leaving the UI stuck on its loading screen.
A specific orchestrator API route (not /) that the frontend depends on during bootstrap, which may be erroring or never responding.
This matches the discussion in #1093 and the self-kill/shell-lifetime issue partially addressed (but not merged) in PR #886.
What happened
Summary
On Windows, Freebuff Desktop opens its window successfully but the UI never finishes loading — it is stuck on the loading screen indefinitely. This has reproduced identically across three consecutive releases (0.0.73, 0.0.74, 0.0.75), and another user reported the same class of failure starting at 0.0.71 (#1093, "the Freebuff shell is gone; shutting down"). I've done fairly deep isolation testing (details below) that rules out GPU, antivirus, and a broken Electron/install, and narrows the likely fault to the renderer bootstrap path (JS bundle / preload / IPC) rather than the backend.
Environment
winverand fill in your exact build, e.g. Windows 11 23H2)C:\Users\<user>\AppData\Local\Programs\@codebufffreebuff-desktop\What happened
Freebuff.exe.MainWindowHandlepresent,Responding = Truein Task Manager).What I already verified (ruling things out)
freebuff-desktop orchestrator listening on http://127.0.0.1:<port>with no errors.Invoke-WebRequest http://127.0.0.1:<port>/returns200 OKwith validindex.htmlcontent.BrowserWindowloadinghttps://example.com) launches and renders fine.--disable-gpu --disable-gpu-compositing --disable-gpu-sandbox --disable-gpu-rasterization.Microsoft-Windows-Windows Defender/Operationalevent log — no entries referencing Freebuff, Electron, or Bun processes.resources\app.asar,resources\orchestrator\,resources\bun\, andresources\orchestrator\ui\index.htmlare all present and intact.Where I believe the bug is
Since the backend (
/) returns 200 and Electron itself works standalone, the failure looks like it's isolated to one of:index.htmlis served.preload.cjsthrowing or failing silently, breaking the IPC bridge./) that the frontend depends on during bootstrap, which may be erroring or never responding.This matches the discussion in #1093 and the self-kill/shell-lifetime issue partially addressed (but not merged) in PR #886.
Related issues/PRs
pr:needs-work)Steps to reproduce
Freebuff.exe.Expected behavior
Freebuff Desktop UI loads normally after the orchestrator starts.
Suggested next diagnostic step (for maintainers or anyone reproducing)
Launch with remote debugging enabled to inspect the renderer's Console/Network tabs directly:
then attach via
chrome://inspectto check for:Happy to run this and attach logs if a maintainer can point me to which endpoint(s) the frontend depends on during startup.
Where does this happen?
Desktop app
Operating system
Windows
Version
0.0.75
Model
No response
Logs or screenshots