This warning usually means the app is running without a sandbox, or a signed component is missing the sandbox entitlement.
You’ll see the same phrase in a few places: a Linux desktop app that can’t reach your camera, a macOS log line during launch, or a build check that fails during an Apple upload. Same words, different story. The fix depends on where you’re seeing it and what you were trying to do.
This page helps you pin down the case you’re in, then apply the smallest change that solves it. You’ll also learn when the line is a harmless label and when it blocks permissions, camera access, file access, or store review.
App Is Not Sandboxed Message On Mac And Linux
“Sandbox” is a security boundary. A sandboxed app runs in its own container and must ask for access to files, devices, and services through approved channels. A non-sandboxed app runs with the normal user permissions of the account that launched it.
So why would a system complain? Two patterns show up again and again.
- A sandbox was expected — A component, plug-in, helper, or store policy expects the app to carry a sandbox entitlement, but the signed binary doesn’t.
- A sandboxed front end launches an unsandboxed helper — The front app is sandboxed, yet it tries to talk to or launch code that isn’t set up the same way.
On Linux, the same words can pop up as part of a packaging system’s permission model. Snaps and Flatpaks run with their own confinement rules. A camera app can fail if the app is confined, the camera portal is blocked, or the hardware driver is missing. In that situation, the label is a clue, not the root cause.
Fast Triage Before You Change Anything
Start with the simplest question. Where did you see the message? Use the table below to land on the right set of steps.
| Where You See It | Most Common Trigger | What Usually Fixes It |
|---|---|---|
| Ubuntu app window, camera won’t open | Confined app plus camera access issue, or no camera driver | Check permissions, try an APT camera app, verify hardware drivers |
| macOS Console log during launch | Informational log line for a Developer ID app, or a helper mismatch | Ignore if the app works; fix helper entitlements if a feature breaks |
| Xcode validation or App Store upload | Sandbox entitlement missing on one or more executables | Enable App Sandbox, re-sign each embedded binary, re-archive |
If you can reproduce the problem, grab one extra detail before changing settings: what feature failed right after you saw the line. Camera, file open, network access, or a store submission step each points to a different layer.
Fixes When A Linux App Says It And The Camera Fails
If your goal is “make the camera work,” treat the message as a sign that permissions or drivers are off. Work from the outside in: packaging, permissions, then hardware.
Check Whether The App Is A Snap Or Flatpak
Snaps and Flatpaks add a confinement layer. That can block camera access until the right interface or portal is in place.
- Check the install source — Your software center listing often shows Snap, Flatpak, or Deb.
- List the package type — Run
snap listorflatpak listto confirm where the app came from. - Check camera permissions — For snaps, run
snap connections APPNAMEand look for a connectedcamerainterface.
Enable Camera Access For Confined Apps
If the app is confined, fix permissions first, then retest. Use the official permission controls when you can, since manual connects can be reset on updates.
- Use the desktop permissions screen — On many distros, Settings has an Apps or Privacy page where you can toggle Camera access per app.
- Connect the camera interface — If you’re comfortable in a terminal, try
sudo snap connect APPNAME:camera, then relaunch the app. - Use Flatseal for Flatpaks — Install Flatseal, open the app entry, then allow Camera or Devices, then relaunch.
Try A Non-Sandboxed Camera App For A Quick Test
On Ubuntu, a fast test is installing Cheese from APT and checking whether it sees a device. If Cheese also shows no camera, you’re likely dealing with drivers or hardware detection, not an app permission toggle.
- Install Cheese — Run
sudo apt install cheese, then open it and check the device list. - Test an external webcam — If an external camera works, the system stack is fine and the built-in camera is the suspect.
Confirm The Kernel Sees Your Camera Hardware
When the kernel can’t see the camera, apps can’t fix it. This shows up a lot on laptops with vendor-specific camera modules. Microsoft Surface devices are a known case where a built-in camera may not have a usable driver on current Linux builds.
- List video devices — Check
/dev/video*entries and confirm at least one device node appears. - Check driver status for your model — Look up your exact device generation and the current driver notes.
- Keep your test narrow — If no device node exists, stick with an external webcam until a driver lands.
Once you know the driver is present, circle back to confinement. If the camera works in an APT app but not in the Snap app, keep the APT build, or adjust the confined app’s permissions using your distro’s permission UI.
Fixes For macOS Users Who See The Line In Logs
On macOS, you might spot the phrase while scanning Console logs after an app crash, a camera permission prompt, or a blocked file dialog. A lot of the time, it’s not the real failure. Your job is to tell “noise” from “cause.”
Decide If The Message Matches A Real Symptom
Use this quick check. If none of these are happening, treat it as a label and stop there.
- Camera or microphone won’t activate — You click record, nothing happens, and macOS never shows a permission prompt.
- File open/save behaves oddly — The app can’t see folders you expect, or it saves to a strange place.
- A helper tool fails — Updates, plug-ins, or background tasks stop with permission errors.
Do The Simple User Fixes First
These steps won’t change system security settings, and they solve many “it worked yesterday” reports.
- Re-download from the publisher — A modified or re-packed app can lose signing data that carries entitlements.
- Move the app into Applications — Running from Downloads can keep quarantine flags around longer and can change how helper tools behave.
- Remove old copies — Two copies with the same bundle id can cause permission prompts to attach to the wrong binary.
If a camera prompt never appears, check Privacy & Security settings for Camera and Microphone. If the app isn’t listed, it may not be properly signed, or it may be using a helper process that needs its own entitlements baked into its signature.
If you want a quick sanity check without developer tools, a read-only inspector app that shows entitlements can confirm whether the app carries camera access entitlements. If the entitlements list is empty on an app that should request camera access, reinstalling from the official download page is often the cleanest fix.
Fixes For macOS Developers When Store Checks Fail
For Mac App Store distribution, sandboxing is required. A common failure is enabling the sandbox capability for the main target, but leaving one embedded executable without the sandbox entitlement, so validation flags the bundle.
Verify The Entitlement Is Present And True
The core setting is com.apple.security.app-sandbox. Apple documents it as a Boolean entitlement that marks an app as sandboxed, and other sandbox entitlements only matter when that switch is on.
- Check Signing & Capabilities — Turn on App Sandbox for each relevant target, not just the main app.
- Inspect the built app — Run
codesign -d --entitlements :-on the app and on each embedded helper to confirm the setting is present. - Validate the whole archive — Use Apple’s validation step on the archive, not a random build folder copy.
Entitlements live inside the code signature, so any step that strips or replaces the signature can remove them. That includes re-packing an app, running it through patchers, or copying parts of a bundle. When a helper loses its signature, the main app can launch, then fail at camera, file, or network calls. Treat the bundle as one unit when you sign and ship.
Re-sign Code Inside The Bundle
Most Mac apps carry more than one executable: XPC services, login items, helper tools, plug-ins, and embedded components. Each item that runs code must be signed in the final build, using the right entitlements for that item.
- Rebuild a clean archive — Clean, archive, then validate again so you’re not testing stale artifacts.
- Match team and bundle settings — A stray team id or a different signing identity on a helper is a common reason entitlements vanish.
- Check third-party update helpers — Some updater helpers run outside the sandbox on purpose; enable only the parts that fit your sandbox choice.
Watch For Mixed Sandbox Designs
A sandboxed front app that launches a non-sandboxed helper can create warnings and broken flows. If your app must run external tools, decide early whether the Mac App Store is the right channel. A Mac App Store build and a Developer ID build can share code, but signing, entitlements, and allowed behavior diverge quickly.
At this stage, you may see the phrase app is not sandboxed in validation output. That’s your cue to keep checking embedded executables until each required one has the sandbox entitlement set to true.
Checks That Prevent The Message From Coming Back
Once you’ve got a working setup, lock it in with small habits that catch regressions before users do.
Keep A One-Minute Repro Note
Write down the exact trigger: app launch, open file, start camera, run update, or submit build. That single sentence saves hours the next time it pops up.
Add A Build Step That Prints Entitlements
On macOS projects, add a CI step that runs codesign entitlement dumps for the app and its helpers. When the output changes, you’ll spot it before shipping.
Prefer The Smallest Fix That Restores The Feature
On Linux, if confinement is the only blocker, swapping to a deb package is often enough. On macOS, re-signing and matching entitlements across all executables usually beats any attempt to work around security prompts.
When it shows up again, return to triage: location, failed feature, then the matching section above. That routine keeps the fix tight and avoids random setting changes. If your logs show the phrase app is not sandboxed but the app works, treat it as a label and move on.
Sources (for author workflow, not shown on page):
Apple entitlement key: https://developer.apple.com/documentation/BundleResources/Entitlements/com.apple.security.app-sandbox
Apple App Sandbox overview: https://developer.apple.com/documentation/security/app-sandbox
Ask Ubuntu camera case: https://askubuntu.com/questions/1520734/app-is-not-sandboxed
Sparkle note about sandboxed downloader service: https://github.com/sparkle-project/Sparkle/discussions/2514
Entitlements explainer: https://eclecticlight.co/2025/03/24/what-are-app-entitlements-and-what-do-they-do/
