The gap it closes
Titah’s permission model guards at the tool layer, and it guards well. But
once a bash command is allowed, it runs with your full rights: rm -rf ~,
curl | sh, a write into ~/.ssh.
The delete axis governs the remove tool. bash never passes through it. No
arrangement of axes fixes that, because the axes describe which tool is being
used and the problem is what the tool can reach.
{ "sandbox": { "bash": true, "network": true } }Reads stay free, writes are confined
Confining reads confines compilers, linters, and git log — you would turn the
whole feature off within a day.
What is confined is writes outside the project directory and temp. That is
the one fence that stops rm -rf ~ without stopping npm install.
network defaults to on, because npm and git need it. Turn it off for a
tighter fence when the work does not.
It fails closed
Seatbelt on macOS, bubblewrap on Linux.
Turn the sandbox on where no sandbox exists and bash is refused rather
than run unfenced. Somebody who enabled it believes there is a fence; running
anyway would leave them believing it while there is none.
titah doctor reports which of the three states you are actually in: on and
available, on with nothing to enforce it, or off.
Off by default
A sandbox changes how commands run, and a change like that must not arrive unrequested. A command that suddenly fails to write somewhere it has always been allowed to write is a failure nobody will connect to a Titah upgrade.
!!! warning “Platform status” Verified on macOS / Seatbelt. The bubblewrap path is written but has not yet been run on a Linux box. Windows has no sandbox at all — and no Titah support in v1 either.
What it is not
It is not a substitute for the permission engine, and not a claim that a
sandboxed bash is safe to allow blindly. It bounds the blast radius of a
command you approved; it does not decide whether to approve it. Both layers are
worth having — see Permissions & undo.