Skip to main content
@reticlehq/electron reaches the two places the renderer cannot: the IPC boundary, and capturePage(). Version 2.8.0. Apache 2.0. Depends on @reticlehq/core. Peer dependency: electron >= 22. No build step.

Why it exists

In Electron the interesting failures happen across IPC. The renderer asks the main process for something, the main process quietly fails, and the renderer-side SDK sees nothing at all. That reads as “this app makes no backend calls” rather than “you are blind to them”.

Exports map

There is no . export. Two subpaths only.

The preload

It must run before require('electron') and before any contextBridge.exposeInMainWorld call. It patches ipcRenderer while those methods are still writable, so ordering is not a style preference.
It patches three methods, and each IPC call then surfaces to Reticle as a network record on ipc://<channel> with initiator: 'ipc': It then exposes window.__reticleIpc through the context bridge, with three members used by the SDK rather than by you:

The main process

installReticleCapture(win): void is a no-op on null or undefined, tracks the window until it closes, and registers the capture handler once for the whole app. The handler calls webContents.capturePage(), writes the PNG into a per-process 0700 captures directory as reticle-capture-<n>.png, and returns the file path rather than the bytes, because the transport has a 64KB cap. It returns null on an empty image or any error, and it refuses fullPage: true explicitly rather than silently returning a viewport shot.

Renderer wiring

The renderer still needs the SDK. A packaged app is a production build, so the connect call has to opt in:
Or, with the Vite plugin, reticle({ desktop: true }).

Desktop setup in full

Electron and Tauri wiring, and what reticle doctor checks for each.
Last modified on August 15, 2026