Before You Submit

I searched the existing issues. This appears related to #1893 and #2161. The v0.9.8 release notes include #2161, so this may be a regression or a missing-model path that the guard does not cover.

Bug Description

A Parakeet model that had worked before a Mac restart was missing when Handy started afterward. Handy 0.9.8 logged that the configured model was unavailable on disk and cleared the selection. Pressing the configured shortcut still triggered a transcription event, which then failed with “Model not found:”. The hotkey remains unusable until a model is restored.

I did not manually remove the model, so I cannot reproduce the external cause yet. CleanerOnePro recorded a cleanup about 19 minutes before Handy first logged the missing model; that timing is only a correlation, not proof it deleted the model. I found no record identifying what removed the files.

Expected: when no model can load, the shortcut should be refused as intended by #2161, and Handy should show an actionable missing-model/re-download state. Actual: the shortcut reaches transcription and returns “Model not found:”.

System Information

App Version: 0.9.8
Operating System: macOS 15.8.1
CPU: Apple Silicon (arm64)
GPU: Apple integrated GPU
Model: handy-computer/parakeet-tdt-0.6b-v3-gguf/parakeet-tdt-0.6b-v3-Q8_0.gguf

Logs

Observed messages: startup reports the model unavailable on disk and clears its selection; the shortcut path later logs “Model not found:”. I can provide a redacted log excerpt if useful.

Activity

pacificalabs16d ago

Follow-up: surviving model blob, missing cache lookup path

After the cache cleanup, I reproduced the startup selection clearing and hotkey failure with Whisper Small English in Handy 0.9.8. The GGUF blob remained in Handy's Application Support/com.pais.handy/model-storage/hub and its snapshot symlink resolved, but ~/.cache/huggingface/hub was absent and the Handy process had no HF_HOME or HF_HUB_CACHE override. This suggests a missing lookup path can make a surviving model appear unavailable; it does not establish what removed that path. This follow-up checked Whisper, not the earlier Parakeet v3 files.

After cleanup, the prior handy.log was absent while Handy was still running. Relaunch created a fresh log, so I could not recover the earlier diagnostic history.

Startup workaround verified: I placed copy-on-write clones of the Whisper and Canary GGUFs in Handy's persistent Application Support/com.pais.handy/models/ directory, removed the Hugging Face cache lookup symlink, restored the previous Whisper selection, and restarted. Handy kept the selection and did not clear it at startup. I verified startup detection only; I did not test a live recording after the repair.

cjpais16d ago

I'm gonna be honest, what you did here is almost break the app intentionally, and like it seems like you had an agent go run amok and make an even bigger mess because some of the things you're pointing out are not even part of the handy code base Application Support/com.pais.handy/model-storage/hub.

With that said, we can definitely give a better warning, but that's what this issue boils down to: is we should just give the user feedback that something is fundamentally broken.

pacificalabs16d ago

Thanks for your feedback , I want to assure you that I didn't set out to break the app intentionally at all, this arose from the use of my usage of CleanerOnePro from Trend Micro, which is meant to free up RAM usage - it also gives a UI option to remove what it denotes "Junk files", which were accumulating to be >2GB in size. When I cleared it out it also removed the models - basically a side effect; I am a huge fan of Handy and your work; Adding an extra folder in Application Support was an innocent attempt to solve this problem locally. Please take my bug report as a good faith reporting, nothing more, nothing less.