-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting
Settings → Data → Open logs gets you the log file, which is the right place to
start for anything not listed here.
SmartScreen, because the installer is not code signed. More info then Run anyway. There is a longer explanation, and how to verify the download if you would rather not take it on trust, in Installation.
The splash screen names the stage it is on, and that tells you which of these it is.
Checking local AI service: Ollama is not running. Start it and relaunch. If Draggy offered to install it and you declined, install it from ollama.com.
Downloading the model: this is genuinely a multi-gigabyte download and it will sit there for a while. The progress bar counts every layer, so it does move even when it looks stuck on one number.
Checking available disk space: Draggy refuses to start a download that would not fit. It needs roughly 10 GB free.
Almost always a model that does not fit in VRAM. Settings → Models shows the
split for each one; anything reporting less than 100% GPU is partly running on
your processor, and the shortfall costs far more than the model size difference
would suggest.
Step down one size. A 4B model that fits entirely in memory beats an 8B model that does not, every time.
Under each reply, with metrics on, is a row ending in something like 6.0s model load. That is Ollama loading the weights, and on a healthy setup you should see
it once, on the first message after launch, and then not again.
Seeing it on every message means the model is being unloaded in between. Ollama holds a model in memory keyed on the context window it was loaded with, so anything that asks for a different window reloads it from scratch. Draggy picks one window per model and grows it only when a conversation genuinely outgrows it, so the occasional reload part-way through a long chat is expected; one per message is not, and is worth reporting as a bug.
This was broken up to and including 1.1.4: the warm-up that ran while you were typing loaded the model at the wrong size and guaranteed a reload on the very message it was meant to speed up. Update if you are on an older build.
That line in the transcript is where Draggy folded the older half of the conversation into notes, because it was approaching the size of the context window. It is working as intended, and it is what stops a long chat hitting the wall and refusing to continue.
The messages themselves are untouched: still on screen, still searchable. The model is working from a summary of everything above that line, so it will remember decisions, names and numbers but not the exact wording of a message from an hour ago. If you need it to have the exact text, quote it back.
The fold happens after a reply, while you are reading, and is abandoned if you send another message first. It should never be something you wait for.
It wrote something like "I'll search the web for that" and then did nothing. This is a model capability problem, not a bug. Models below roughly 4B parameters are unreliable at tool calling.
Either use a larger model, or turn web search to On rather than Auto, which puts the instruction where the model cannot miss it.
It should not, and every child process Draggy starts is launched with its
console suppressed. If you still see one, it is worth reporting with what you
were doing at the time. The log at Settings → Data → Open logs will say which
subprocess ran.
Up to and including 1.2.1 this happened whenever an extension started, because
extensions were launched through npx, which runs a package through a cmd.exe
shim. They are installed once and run directly now.
Settings → Extensions shows the error under the entry, including whatever the
server printed on the way out.
Not configured yet: a required field is empty; open the setup fields under the entry.
Did not answer in time: npx could not fetch the package, or the server
needs a runtime you do not have. The panel shows the exact package name; check
it against npm.
Stopped (exit code 1): it started and then rejected something, most often a credential.
A first start is slower than the rest, because the package is being downloaded. See Extensions.
Permission denied: the microphone was refused. On Windows, check
Privacy & security → Microphone and that desktop apps are allowed.
No speech voices are installed on this system: your OS has no speech synthesis voices and the neural voice is unavailable in your language. Install a system voice, or switch the interface to English and use the natural voice.
It downloads and then fails: check the log. If the talk model could not be fetched, Draggy falls back to your chat model and carries on, so this shows up as voice mode working but the model name in the footer not being the one you expected.
Its own voice is reaching the microphone. Headphones fix this completely. Short of that, lower the output volume; echo cancellation is doing real work but it cannot beat a loud speaker next to a sensitive microphone.
Draggy extracts the text layer of a PDF. A scan, or a set of exported images, has no text layer, and Draggy says so rather than guessing. It does not run OCR. Run the file through an OCR tool first and attach the result.
Password-protected PDFs are refused for the same kind of reason: the text is there but cannot be read without the password.
Set the interface language correctly in Settings → Language. It tells the
recogniser what to expect and matters more than you would think. Beyond that, a
close-talking microphone is worth more than any setting.
Try the Ad blocker switch in the browser toolbar settings button. The filter lists are written to avoid breaking sites, but a paywall or a video player occasionally objects, and the page reloads when you flip it.
If the page instead says it needs to verify you are human, that is a Cloudflare or CAPTCHA challenge. Pass it yourself in that window; the model can read the site afterwards, because it shares the session. Draggy does not try to defeat those checks.
read_url and the browser tool only open http and https addresses on the
public internet. A file:// path, an address on your own network, and the app's
internal schemes are all refused.
This is deliberate. The model reads pages other people wrote, and one of those pages saying "now read this local file" would otherwise be worth a try, with the contents arriving in the conversation and leaving in the next search query.
To have Draggy read a local document, attach it to a message instead, or index the folder into the Document Library.
Providers rate limit. Draggy tries several in turn, and "no provider would answer" is reported differently from "the web had nothing", so read the message carefully. Waiting a minute usually resolves it. Your own SearxNG instance avoids the problem entirely.
unable to verify the first certificate while running npm run electron:build
means something on the machine is intercepting TLS (antivirus, a corporate
proxy, a VPN) with a root certificate Windows trusts and Node does not.
Tell Node to read the system store:
$env:NODE_OPTIONS = "--use-system-ca"
npm run electron:build
Tagged releases build on GitHub's runners, which have clean trust stores, so this only affects local builds.
Check the Ad blocker switch in the browser toolbar is on. YouTube's adverts come from the same server as the video, so they are removed by scriptlets that edit the player's response rather than by blocking a request, which means the rules change often, and a stale filter cache can lag behind. The cache rebuilds when the list set changes; restarting Draggy is enough.
Draggy stops what it started. On the way out it closes any in-app browser windows, stops every extension server, kills a code run that is still going, and shuts down Ollama if Draggy was the one that started it.
An Ollama that was already running when Draggy launched is left alone, on
purpose. It may be serving something else, and killing a service Draggy does
not own would be worse than leaving it. On Windows the Ollama installer adds a
startup entry and a tray icon, so it usually starts at login and has nothing to
do with Draggy: quit it from the tray, or remove Ollama.lnk from
shell:startup if you would rather it did not start itself.
If a Draggy process really is left behind, the log at
Settings → Data → Open logs records each shutdown step and names the one that
failed.
Updates only work in an installed build. If you are running from source the panel will say so.
Otherwise, check that the installed version is older than the newest release. An automatic check happens twenty seconds after launch and every six hours; Check now forces one.
It is a small language model running on your desktop. It will be wrong sometimes, particularly about recent events, version numbers and arithmetic. Turning on web search helps with the first two and code execution helps with the third.
If it is wrong about your own documents, the passages it retrieved are probably the problem rather than the model. See Document Library.