Troubleshooting

Troubleshooting

• Open Apex on your phone. Put the phone on the same network as the machine Apex runs on. On the machine, open the DHD page and turn on Apex | Node [local], under the DHD options — that is the whole setup: Apex restarts her own bridge, and the row confirms On your network when it is live; there is no separate restart step. On the phone, open the address that same row shows (it looks like http://192.168.1.5:8675 — the row's button copies it) and type the access code from the row; the phone's browser is remembered after that. If the phone cannot reach her: check it is not on mobile data, check the row's live state line reads On your network, and check the code is the one the row shows now — regenerating the code shuts out every phone let in before. If the row names a failed restart step instead, press Restart bridge there, or quit Apex fully and relaunch. On the phone, the dashboard wears its small-screen layout: a slim bar stays pinned at the top — the hamburger button hugs its left edge with Apex | powered by Navi right beside it, the hamburger opening the menu (which slides in from the left), and the dock button hugging the right edge, opening the whole status column (which slides in from the right) — each a full-width overlay that closes itself when you pick where you're going. This machine itself never needs the code.
• The dashboard shows some other page. Something else holds port 8675 — the launcher names it by its page title; find it with ss -ltnp | grep 8675.
• “BRIDGE OUT OF DATE”. An older bridge process is still running after a reinstall. Quit the app fully and relaunch.
• Chat 400s. The bridge uses the model id the server itself reports (navi); on failure the server's own error text is shown — check navi.llamafile.log.
• She doesn't answer. Every chat request is bounded — at most 1,024 tokens of generation — and the bridge waits up to ten minutes for a CPU-bound reply to finish. If the wait runs out, the message in the thread says the model was still generating; that never means the server died. An empty reply from the model is reported the same way, in the thread, rather than swallowed as silence.
• The llamafile won't start. Press Connect — in app-launch mode the bridge starts the server itself and reports the specific failure.
• Her voice is not installed. Her voice is an extra the installer offers — it is not part of the main app. Say yes when the installer asks, or follow the step Settings → Voice names. Until then she still works; she just answers in writing instead of out loud.
• A chip will not run. Open it in Chip Studio and read the red squiggles first — a chip needs a command, a use line, and a run() before Navi can run it, and the bar under the editor names what is missing. A chip that only declares an output is not broken: it shows that output instead of running code.
• The catalog finds nothing. The catalog is a live search of GitHub. With no network it finds nothing, and when GitHub itself is busy the search says so instead of pretending the shelf is empty — wait a minute and press Search again.
• She answers without using my pack. Only packs switched on feed her answers. Check the switch on the Packs tab. When a pack does help, the small label under her message names the pack and the document — no label means no pack was used for that answer.
• The call will not start. A call needs her voice installed and switched on, and her model connected. Settings → Voice names the missing piece — fix that one thing and try again.
• Dark Liquid Glass looks solid, not frosted. That is the design working as intended, not a bug: where your system cannot do backdrop blur, the theme falls back to the same colors, solid and fully readable. If scrolling ever feels stuttery on weak built-in graphics while the glass theme is on, pick any other theme in Settings → Appearance — the flat themes cost the graphics chip almost nothing — or turn on Potato mode there, which suspends the blur.
• Known issue: she cannot hear me in the desktop app. Field report from the operator's Framework 13 (Pop!_OS), 2026-11-07, and noted in Settings → Voice at his request: in the standalone window, the microphone does not reach Navi — push-to-talk and calls get no working mic — even with the OS permission allowed. Her shell is built to grant the dashboard's mic requests, so the break is somewhere in that chain and the fix is still being worked on; it is not fixed yet. What works today: typing. The call panel takes typed lines and she answers out loud; Chat takes typed messages the whole time. If your mic works in the app, you are ahead of the field report — the Settings → Voice tab shows what this window's own mic requests did this session, which helps narrow it down.