How Deno and macOS sandboxes make a program read-only by force

How do you stop a program from writing anything, rather than asking it nicely not to?

Deno won’t let a script touch files or the network unless it’s been given permission, and macOS can wall a process off with a sandbox profile. I’ll look at how both enforce it, then spend a week building a check that proves a command-line tool can’t write.

Format: Teardown
What I’ll build: A launcher that starts a command-line program in an operating-system sandbox with no write access, plus a check that tries every way to write it can find and reports any that get through.
What I’ll reuse: A read-only launcher and preflight check for AI assistants that are meant to review code, never change it.
Used by: Bezl
Status: Planned · Nov 2026

What I’ll look at

How Deno decides what a script may touch, and what it does when something isn’t allowed. How macOS sandbox profiles, the kind Chromium uses for web pages, describe what a process may read and write. And what a child process inherits, since a program that can start another program can often slip its own limits.

My guess

I expect a tool’s own settings aren’t enough, because plugins, hooks and helper programs it starts don’t always respect them. Only a limit the operating system enforces holds for everything the program starts.

How I’ll prove it

I’ll list the ways a program can try to write: files, temporary folders, settings, a helper program, a plugin. I’ll run each one under the launcher and check that every attempt is blocked and logged.

I’ll also check the tools still work normally when all they do is read.