The Temple of Osiris on macOS: Silent Launch Failure Caused by Documents Folder Permissions

The Temple of Osiris (game) on macOS: When It Launches… and Immediately Quits

I installed The Temple of Osiris (game) on a MacBook Pro 14" (M1 Pro, macOS Sonoma 14.4). The slug clearly points to Lara Croft and the Temple of Osiris, and judging by the category, this was a file-managed standalone build rather than a store-managed install. I was setting it up inside my usual OrchardKit workflow so I could keep track of external titles separately from App Store purchases.

The goal was simple: launch it, test performance on Apple Silicon, move on.

Instead, I got the most unhelpful behavior possible: click → icon bounces once → nothing. No crash dialog. No “unexpectedly quit.” Just silent exit.

That’s always a red flag.

First assumption: Gatekeeper drama

Because this wasn’t a Mac App Store build, I assumed Gatekeeper was blocking something behind the scenes. Sonoma has been strict about notarization for a while. Apple’s explanation is here:
https://support.apple.com/en-us/HT202491

System Settings → Privacy & Security did show the standard “Open Anyway” prompt after first launch. I approved it. Tried again.

Same bounce. Same disappearance.

So it wasn’t basic Gatekeeper refusal.

Second attempt: Rosetta confusion

Even though the machine is Apple Silicon, a lot of older titles still rely on Intel binaries. I checked the architecture:

file /Applications/The\ Temple\ of\ Osiris.app/Contents/MacOS/*

Intel-only. No universal binary.

Rosetta should handle that automatically, but sometimes the first launch doesn’t trigger installation properly. I manually installed Rosetta just in case:

softwareupdate --install-rosetta

Rebooted (probably unnecessary, but I wanted a clean slate).

Launched again.

Same behavior.

Now I opened Console and filtered by the process name. That’s where things got interesting: repeated logs about missing write permissions inside ~/Documents and an error referencing “savedata initialization failed.”

That pointed to something different — not execution, but storage.

The real issue: Protected folders

Since macOS Catalina, Documents/Desktop/Downloads are protected locations. Apps must explicitly request access. If they don’t handle the permission prompt correctly, file operations fail silently. Apple’s privacy model overview is here:
https://support.apple.com/en-us/HT210638

This title was trying to create its save directory under ~/Documents/TempleOfOsiris/ on first launch. But because it never properly triggered a TCC prompt, macOS denied the write. The game didn’t handle the failure gracefully. It just quit.

Classic.

The app wasn’t even listed under Privacy & Security → Files and Folders. That meant the permission request never completed.

At that point I bookmarked this page because it breaks down how this build behaves on macOS systems and why file access can fail on newer versions:
https://smohamad.com/file-management/84643-the-temple-of-osiris.html

It aligned perfectly with what I was seeing in Console.

What Actually Worked

Instead of trying to force permissions through the UI, I did three things:

1. Removed quarantine flag (just in case first-run trust was incomplete):

   xattr -dr com.apple.quarantine /Applications/The\ Temple\ of\ Osiris.app

2. Reset file access permissions for the bundle:

   tccutil reset All com.feralinteractive.templeofosiris

   (Bundle ID confirmed with mdls.)

3. Created the save directory manually and pre-granted access.

I launched the game from Terminal:

/Applications/The\ Temple\ of\ Osiris.app/Contents/MacOS/The\ Temple\ of\ Osiris

This time macOS prompted for Documents folder access.

Allowed.

The game continued past the splash screen and loaded into the main menu instantly. No crash. No bounce-and-die behavior.

After that, subsequent launches from Finder worked normally.

Why This Happened

This isn’t about performance or Apple Silicon incompatibility. It’s about the order of operations during first launch. If the title tries to write to a protected folder before macOS fully registers it as trusted, TCC denies access. If the developer didn’t code a fallback or user-friendly error, the process just terminates.

On App Store builds, this is usually smoother because sandbox entitlements are enforced consistently. For reference, the official App Store search listing is here:
https://apps.apple.com/us/search?term=Lara%20Croft%20and%20the%20Temple%20of%20Osiris

And the official publisher page (Feral Interactive) provides macOS details:
https://www.feralinteractive.com/en/games/laracrofttempleofosiris/

Store-managed updates reduce these permission edge cases. Direct-distribution builds depend more heavily on correct signing + notarization + runtime prompts.

If I Were Installing It Again

I’d do it in this order:

• Clear quarantine immediately after copying to Applications.
• Launch from Terminal once to observe permission prompts.
• Grant Documents access the moment macOS asks.
• Only then troubleshoot performance or architecture.

Total fix time once I understood the root cause: about 15 minutes.

Time wasted assuming it was an Apple Silicon crash: closer to 45.

After resolving file permissions, performance on the M1 Pro was solid — stable 60 FPS at high settings, no shader stutter. So the engine itself isn’t the issue. It just needed macOS to allow it to write save data.

It’s a good reminder that on modern macOS, a “silent quit” is often a permissions problem masquerading as instability. Once you treat file access as part of the launch sequence, the behavior makes sense.

The game wasn’t broken. The OS was just doing its job.