DEV Community

Andrew
Andrew

Posted on

ChatGLM Desktop on macOS: When Silent File Permissions Break an Otherwise Working App

Hey — quick field note from yesterday. I was poking around with ChatGLM Desktop (app) from OrchardKit on my Mac and ran straight into one of those macOS problems that feels like the app is broken, but really isn’t.

I’m on an M2 MacBook Air, macOS Sonoma 14.3. The goal was simple: install the desktop client, point it at a local model, and see how usable it feels compared to running things from the terminal. Installation itself went smoothly — drag to Applications, launch, done. Or so I thought.

What I tried to do

I wanted to launch the tool, load a model directory, and test a few prompts offline. Nothing exotic. This is exactly the kind of utility that should “just work” once it opens.

What broke

The app launched, but then immediately behaved like it was half asleep. The window appeared, UI elements rendered, but loading a local model failed silently. No crash. No warning dialog. CPU usage spiked briefly, then nothing. Clicking buttons did nothing useful. At first glance it looked like a buggy build or an incompatible model format.

Classic macOS ambiguity.

First attempts (mostly wrong)

My first instinct was the usual stuff. I re-downloaded the archive, verified the checksum, and reinstalled. Same behavior. Then I tried running it after rebooting, thinking maybe some leftover process was interfering. Nope.

Next, I went down the rabbit hole of model compatibility. I tested two different model folders, renamed paths to avoid spaces, even moved everything into /Applications/Models just to rule out permission weirdness. Still nothing. The UI stayed responsive, but the core functionality was dead.

At this point I was pretty sure it wasn’t actually “crashing” — it was being blocked.

What clicked

The turning point was noticing that the app never asked for any permissions. No file access prompt. No “allow access to Documents” dialog. macOS usually nags you aggressively about this, but sometimes it just… doesn’t.

I checked System Settings → Privacy & Security → Files and Folders, and sure enough, the app wasn’t listed at all. macOS simply hadn’t granted it permission to read external directories, which explained why loading local models failed silently.

Apple’s own docs on how sandboxed apps handle file access helped confirm the theory (support.apple.com has a good breakdown of how these permissions work and why apps can fail quietly if they’re missing).

What actually worked

The fix was annoyingly simple once I knew what to do. I manually added the app by triggering a file open dialog from inside it, selecting a folder explicitly. That action finally forced macOS to ask for permission. After approving access and fully quitting the app (not just closing the window), everything worked on the next launch.

Models loaded instantly. CPU usage made sense. No weird UI freezes. It felt like a different application.

I bookmarked this page during the process because it described the macOS-specific behavior I was seeing almost exactly, and reassured me I wasn’t dealing with a broken build: https://planetgpa.com/developer/37199-chatglm-desktop.html

If I had to do it again

Here’s the mental checklist I wish I’d followed from minute one:

  • Don’t trust a “working” UI on macOS — silent permission failures are real
  • Force a file picker early to trigger Files & Folders access
  • Fully quit and relaunch after changing permissions
  • Assume Gatekeeper and privacy layers before blaming the app

For reference, Apple’s developer docs on app sandboxing and file access explain why this happens at a system level (developer.apple.com has a solid overview), and you can always sanity-check whether you’re running the expected build via the Mac App Store search on apps.apple.com if a listing exists.

Anyway — the tool itself is fine. Solid, actually. It was macOS doing its usual “I’m protecting you but I won’t tell you how” routine. Once you get past that, everything behaves exactly as you’d expect.

Top comments (0)