Both operating systems will probably stop you the first time you open Runi. That is because our builds are not signed yet, not because anything is wrong with the download. Here is each warning and what to do about it.
Windows warns that the publisher is unknown#
Our code signing certificate is not in place on every build yet. An unsigned installer from a publisher SmartScreen has not seen gets this warning by default, and will keep getting it until reputation accumulates behind a signed identity.
Treat it as a real warning, not a false positive. The file genuinely is unsigned, so satisfy yourself the download came from tryruni.com before you continue.
If you are satisfied the download came from us: More info, then Run anyway. If you are not satisfied, which is a reasonable position for an unsigned binary, ask us and we will tell you where signing stands instead of talking you past a security prompt.
The same root cause. An unsigned Electron installer that writes to a user profile directory is a shape some engines flag heuristically.
Check the file against the release we published before allowing it. If your organisation blocks unsigned binaries by policy, that policy is doing its job. Wait for a signed build, and tell us you are waiting so we know it matters.
macOS refuses to open it#
Gatekeeper, for the same reason: the macOS builds are not yet signed and notarised.
Apple's own supported route, once you are satisfied the download is genuine:
- Drag Runi to Applications first. Launching from the mounted disk image causes its own problems.
- Control-click the app and choose Open, then Open again in the dialog.
- If that route is not offered, go to System Settings → Privacy & Security, scroll to Security, and choose Open Anyway beside the blocked app.
An Intel build on Apple silicon, or the reverse. Symptoms range from poor performance to refusing to launch.
Check the Apple menu → About This Mac, read the Chip line, and download the arm64 build for Apple silicon or x64 for Intel.
You used the portable build#
The portable build unpacks itself to a temporary folder that disappears when you quit. Runi refuses to connect agents from it, because the connection would point at a file that stops existing. There is also nothing installed for an update to replace.
If you connected from one before, the doctor names the missing path:
FAIL hooks registered but pointing at missing file(s):
C:\Users\…\Temp\2F8B\relay-hook.cmd — reinstall from the appInstall Runi properly from the download page, then reconnect your agents. The stale entries are replaced.
Updates#
Updates are applied on restart. A window left open for a week is a week without the update.
Quit Runi entirely, including from the tray if it is there, and start it again.
Hooks re-read from disk on every run, so they pick the new daemon up immediately. MCP servers are long-lived and do not.
Restart the agent sessions the doctor names:
warn generation 2 MCP servers still running the previous daemon:
pid 41288 (cursor, started 5 h ago), pid 41402
(claude-code, started 5 h ago) — restart those sessionsThe app will not start, or starts blank#
Quit fully. Check the tray and the task manager, then start again. A second instance behind the first is the commonest explanation for a window that never appears.
Reinstall over the top. Your configuration lives in ~/.relay and survives a reinstall, so you will not have to reconnect anything.
Check the daemon separately. It runs even when the window does not:
$ runi doctor --offlineIf that reports a healthy machine, the problem is the window and not Runi, and the sessions you ran meanwhile were still captured.
Reporting one#
Email us with
your operating system and version, which build you downloaded, what you saw,
and the output of runi doctor --offline if the app got far enough
to install one. Two founders read that address and there is no queue in front
of them.