Troubleshooting

Start with nanomuse doctor: it prints the config file in use, the data directory, the model and endpoint (and whether a key is set), the tools and connectors, and makes one call to the model. Most of the problems below show up there first.

The phone cannot open the URL. Start with --host 0.0.0.0 (the default binds to localhost only), make sure both devices are on the same network, and allow the port through the machine's firewall. The URL shown uses the LAN address the server could detect; if it is wrong, use the machine's address from ip addr / ipconfig with the same #token= part (the token rides in the link's fragment, never in a query string; a ?token= link from before 0.1.31 is refused with a message saying so).

"web app not built" on start. You are running from a checkout without the built front-end. cd web && npm install && npm run build, or install the package instead.

"port 8787 on 127.0.0.1 is already in use by corein 1.0.1" on start. A corein is already serving there (an earlier nanomuse serve, the daemon, a container), and serve stops before touching the data directory. Open that one in the browser, or stop it before starting another; --port 8790 runs this one beside it. By another program means something else holds the port: stop it or choose another port.

Replies come back in the wrong language. With agent.language = "auto" the system prompt names the language of your latest message (detected by script). If a model still drifts, set a fixed language in You → Reply language or agent.language = "English".

The beginning of a streamed reply is missing. Some proxies that inline <think>…</think> into the content drop the first tokens after </think> on the server side. Non-streaming responses are complete; set stream = false under [llm].

The model never calls tools. The endpoint probably ignores the tools field without an error (an endpoint that rejects it is handled by the default tool_mode = "auto"). Set tool_mode = "prompt"; tools are then described in the system prompt and parsed from <tool_call> blocks.

"does not support tools" in the log, then the agent carries on. That is auto doing its job: Ollama refused function calling for this model, so tools are described in the prompt from then on. Pick a model with a tool template (qwen3:8b, llama3.1:8b) for better results on long tasks.

Empty replies, or Ideas that stay on the starter list, with a reasoning model. DeepSeek's thinking variants and the OpenAI o-series count their reasoning against max_tokens; on a hard prompt they can spend the whole budget thinking and return nothing (finish_reason = "length"). corein asks once more with four times the budget when that happens. If it keeps happening, raise max_tokens under [llm] (16384 is a sensible value for these models).

429 / rate limits. Requests retry with exponential back-off (max_retries, default 5). Lower agent.max_steps, or add web_fetch to always_ask_tools to slow the loop down.

An approval card never appears in the terminal. nanomuse daemon and --auto run in Sentinel auto mode by design. Use nanomuse chat or the app for interactive approvals.

"Sentinel blocked" for something you wanted. Check nanomuse audit -n 20 for the reason: a deny rule, deny_tools, or taint (private data read earlier in the conversation plus a new network destination). Add the host to egress_allowlist or approve once.

Email tool returns nothing useful. With scrub_secrets = true one-time codes and reset links are removed before the model reads a mail; that is intentional. Check IMAP settings with nanomuse config show and the vault entries with nanomuse vault list.

Playwright fails to install Chromium. Older distributions are not supported by recent Playwright builds. Use the Docker image or leave browser.enabled = false; web_fetch covers most reading tasks.

corein Desktop shows "corein could not start", or "corein's host stopped". The shell starts the dsh Host as a child process and writes its own lines and the Host's to ~/.nanomuse/desktop/desktop.log (NANOMUSE_DESKTOP_HOME moves the folder). The dialog quotes the error; Copy details puts the versions, the end of the log and the Host's last output on the clipboard for an issue, Open the log folder opens the file. A Host that stops later is restarted once; the next dialog offers Restart. The usual cause after an update on Windows is the profile's plugin link pointing at the old install folder (EEXIST: file already exists, symlink …; fixed in 0.1.40, which remakes the link, and the message names the path to remove by hand should that fail). A first start that takes minutes, on Windows above all, is not a failure: the Host loads some 20 000 files that the real-time scanner checks once, and up to 0.1.41 the shell gave up at 120 seconds while the Host was still loading; it now waits while the process runs, says Still starting after two minutes with the Host's last lines, and asks after ten whether to keep waiting. Updates are not installed on their own: the tray's Downloads (check for a newer version) opens the releases page. Details in desktop.md. (Up to 0.1.29 the desktop was a different program, the Python runtime in an Electron shell, with its log at ~/.nanomuse/desktop-app.log; the two items below are from that time.)

"The data folder … is not writable" / "cannot write to the data directory" right after installing (Windows, 0.1.20–0.1.21). The runtime created its workspace folder relative to wherever the launcher started it (C:\Windows\System32 when the installer opened the app) and stopped when that failed. Since 0.1.22 the workspace defaults to <data dir>\workspace and the shell starts the runtime inside its data folder; update, or set NANOMUSE_WORKSPACE for an older version.

macOS: Finder "can't complete the operation … error code -36" while dragging fomo.corein.in out of the dmg (0.1.20–0.1.21). The image was HFS+; since 0.1.22 the dmg is APFS and the release also carries a .zip of the app: download it, double-click to unpack, drag fomo.corein.in to Applications.

macOS: "corein.app is damaged and can't be opened" or "Apple could not verify…". Builds made without an Apple developer certificate are ad-hoc signed, so macOS asks once (a release signed and notarized with the project's Developer ID opens without the question; desktop.md says how that is done). Open it, dismiss the dialog, then System Settings → Privacy & Security → Open Anyway (or, from a terminal, xattr -dr com.apple.quarantine /Applications/corein.app). Windows shows "Windows protected your PC" for the same reason: More info → Run anyway.

Linux: the hands look but do not act; clicks land nowhere, or typed * comes out as 8 (0.1.37). Two X11 bugs fixed in 0.1.38. The glow the app draws around the screen while the hands work is an X window whose click-through shape X11 forgets each time it maps, so the clicks of 0.1.37 went into the glow itself (and a type could end up in the app's own composer); and libnut dropped Shift for the symbols of the US layout. Update (0.1.37 has no workaround). Still off after the update: check ~/.nanomuse/desktop/desktop.log for operator: available · display W×H (scale N); not available (Wayland session …) means a Wayland login (choose Ubuntu on Xorg on the login screen; the hands cannot work under Wayland and say so in Settings → Computer use's Take a test shot and in the chat). display is the X root in pixels; a click the app says it made at x,y can be checked with DISPLAY=:0 xdotool getmouselocation. A picture that is all black usually means no window manager is running (Electron's capturer needs one; the runtime then uses its own capture). A click that lands a few pixels beside a small button (the gap between two calculator keys) is the chat model's aim, not the hands: the pointer goes exactly where the model said (the log line and getmouselocation agree). Larger targets, keyboard shortcuts and typing are the reliable way through such screens (the agent itself switched to typing 12*34 + Enter when its key clicks missed).

The Android app says "Refused by the relay; sign in again" under Devices. The relay no longer accepts this phone's key (signed out everywhere, or the account was deleted). Sign out and in again on the Account screen; the hub joins again on its own.

The chat says the model provider's content check declined the request. The provider that answers (corein Cloud's upstream, or the vendor behind a key of your own: Alibaba Cloud's DataInspectionFailed, for one) read something in the conversation it will not process, and said so before any model ran. It is not an outage and nothing retries it by itself: the card offers Try again and New chat. Different words usually get through; if the refusal comes back, the words it objects to are probably earlier in the conversation, and a new chat is the way on. On the relay's Health page these refusals are counted apart from upstream errors, since they say nothing about the provider's health.

Reset everything. Stop the server and delete ~/.nanomuse (or your data_dir). The vault key lives there too, so export secrets first if you need them.