Model-command isolation
When the model runs a command in your project, such as a build, a test or a script, the command runs on your computer under your own account. Since 0.19.0, Rulith keeps those commands away from the credentials Rulith stores on this computer. How far that goes depends on the operating system, and some gaps remain. This page states both.
This covers every command a Tool starts through this computer's Worker, such as the engineering tools' builds and tests, together with every process those commands start, including background jobs.
On every system
- Commands start without Rulith's keys or tokens in their environment. Rulith's own variables and credential-shaped variables (API keys, tokens, passwords, database URLs and cloud-provider credentials) are removed first.
- Rulith's web tools refuse loopback, private and link-local addresses, including this computer's Rulith ports.
- The app's own control routes accept only requests from its page's browser session.
By operating system
| System | What commands get |
|---|---|
| Windows | Commands, and every process they start, run at low integrity. The folders where Rulith keeps its credentials are marked unreadable to low-integrity processes, including files written there later. Before every command, Rulith checks that each of those folders is protected, and refuses to run the command if one is not. The open project folder and the tool folder are writable for commands. A project folder's previous setting is restored when access is revoked, the Agent is removed from this computer, or this computer is signed out. |
| Linux | Commands run in a bubblewrap sandbox: the system is read-only, only the project folder and the tool folder are writable, and Rulith's credential folders are hidden. The network stays available; this computer's Rulith ports require secrets that commands cannot read. If bubblewrap (bwrap) is not installed, commands do not run. |
| macOS | Not isolated yet. Commands run as ordinary processes of your account and can read what your account can read, including the credentials Rulith keeps on this computer. Only the protections listed under "On every system" apply. |
On Windows and Linux isolation is on by default and fails closed: if it cannot be set up, commands do not run. Settings → Advanced → Diagnosis in the app shows whether model commands are isolated on this computer, and lists any folder that could not be protected and why.
What you may notice
- A folder that contains, or is inside, a folder where Rulith keeps its data cannot be opened as a project. This includes your home folder itself,
~/.rulithand, on Windows,%LOCALAPPDATA%. Choose a folder that holds no Rulith data. - On Windows, toolchains installed in your user folder, such as Python, npm or cargo, run normally. Operations that need a higher integrity level fail, for example writing to system locations or some COM and WMI calls. Ordinary builds and tests inside the project are not expected to be affected.
- On Windows, isolation needs the .NET Framework C# compiler (
csc.exe) that comes with Windows. On a reduced Windows installation without it, commands are refused. - On Linux, a background job ends when the tool call that started it ends.
Turning it off
Settings → Advanced → Model-command isolation has one switch for each Agent set up on this computer: Run without isolation (not recommended). It is off by default and shown only on Windows and Linux.
Turning it on asks first, Run model commands without isolation?: "Commands the model runs through the engineering capability will be able to read everything your account can read on this computer, including Rulith's own credentials. Turn this on only if isolation cannot work here and you accept that risk." Only Run without isolation turns it on; Keep isolation leaves it off. The page then says whether the Agent restarts on this computer now, once any command it is running finishes, or takes the change at its next start. Diagnosis names the Agents whose isolation is off.
Turning the switch off again asks nothing. Before that Agent's Worker starts isolated again (or at once, when no Worker is running), Rulith ends what model commands started without isolation and left running, detached background jobs included. Under the Agent's switch the page names what was stopped, and anything it could not stop: stop those yourself, or restart the computer.
Gaps that remain
- macOS is not isolated.
- Other files your account can read. Only Rulith's own credential folders are protected. Commands can still read other files your account can read, such as other programs' settings, SSH keys, or a browser profile that may hold a Console session.
- The network. Commands can reach the network, including other services on this computer, such as a local model server. Only Rulith's own ports are protected, by secrets that commands cannot read.
- Copies. A copy of a credential file made outside Rulith's folders is not protected. Rulith does not make such copies.
- The page address. When Rulith starts, its terminal output includes the page's address with a session token. Do not redirect that output to a file that commands can read, such as a log inside the project.
- Proxies. When Rulith's web tools go through an HTTP proxy, the proxy resolves host names, so Rulith cannot see which address the proxy actually connects to.
- Uninstalling. Uninstalling does not restore the settings of project folders that are still open, and leaves Rulith's work folder (on Windows,
%LOCALAPPDATA%\Rulith\work) in place. Sign this computer out before uninstalling to restore the project folders. - Windows drives other than the system drive. To protect a folder there, Rulith may add one permission entry for your own account. It stays on Rulith's credential folders and is removed from a project folder when access ends.
- Linux testing. The sandbox's configuration and its refusal without bubblewrap are tested; a full run on a machine with bubblewrap installed has not been completed yet.