Skip to main content
A host machine runs programs installed on the host running Mirage, such as python3, node, tsx, ffmpeg or a vendor CLI. A program sees the host’s files and network, not the workspace mounts; to reach the mounts, give it a FUSE folder. Nothing confines it unless the machine has a sandbox. Python SDK and Node only.

Installation

Install the programs you want to run on the host. home selects only the Python interpreter. Without it, Mirage uses MIRAGE_LOCAL_HOME, then the interpreter running Mirage (Python) or python3 on PATH (Node).

Usage

captures defaults to @python (python3 and python). Add names such as node or tsx, or @external for every program Mirage does not have itself. Mirage’s own commands, pipes and redirects stay in Mirage: ffmpeg -i in.mp4 out.webm | wc -c sends only ffmpeg.

Sandbox

A sandbox block confines each program through Sandlock, with Landlock and seccomp: it reads only the paths you grant and writes only the ones you allow. Linux only. Install the sandlock CLI on PATH; the full ruleset needs Linux 6.12 or later. With a sandbox, captures defaults to @external; name @python to run the host’s python3 under it too.

Sandbox behavior

  • Under a system_time, programs see that time through libfaketime when it is installed, and the host’s clock without it.
  • An interpreter installed outside the system paths needs an fs_readable grant.
  • Host credentials are not passed to the program.
  • A workspace whose network limits anything, or whose policies judge connections, runs nothing here: the program connects from this host, around both. It answers Permission denied, exit 126.
  • Mirage does not create the FUSE folder or bind it to a session.
  • Program lookup uses the sandbox’s PATH, with the CLI’s system default when the session does not set one. Add directories such as /usr/local/bin to the session’s PATH when required. Missing-program diagnostics come from Sandlock.
  • A working directory absent from the host refuses the command with exit 126.
  • A timeout kills the program.

Connecting the workspace

A host program opens host paths, not the workspace’s. To give it workspace files, expose a mount as a FUSE folder, and under a sandbox grant it in fs_writable, or fs_readable for read only:
After the folder is mounted, run the shared workspace file check.
  • Put the folder at the mount’s own path when you can, so a path typed in the shell names the same file in the program.
  • Calls into the folder follow mount modes and policies. A folder added in code with a session, add_fuse_mount(prefix, mountpoint, session_id) or addFuseMount(prefix, mountpoint, sessionId), also follows that session’s permissions.

Python compatibility

python3 is the same Mirage command on every Python runtime: Mirage reads the script from the workspace and checks it like any file, and a host machine runs it on the host’s interpreter. Every other program is a plain host program. Python module availability and file modes come from the host interpreter. Mirage does not replace them with a subset. Workspace paths become host paths only when exposed through a FUSE folder. Examples below assume that folder is mounted at /data.

open()

Files are host files, including any FUSE folders. Modes and modifiers follow the host interpreter’s Python version.

File objects

os

pathlib

sys

Runtime globals

  • __file__: The script’s workspace path; tracebacks use that path too.

Runtime behavior

Notes

  • A workspace whose network limits anything, or whose policies judge connections, runs nothing here: the program would connect around both. It answers Permission denied, exit 126.
  • A timeout kills the subprocess. kill sends it the signal it names, then KILL a second later if it is still running. A program that handles the signal and exits gives wait its own exit status, as in Bash.