mirage
strukto-ai · strukto-ai/mirage
A virtual terminal that provides agents with a sandboxed environment, virtualized CLIs, and unified data access.
The World's First Virtual Terminal for AI Agents
Preview
What you can do with it
- Give an agent secure access to files across Slack, S3, and local storage
- Run sandboxed Python scripts that cannot access the host machine
- Coordinate complex pipelines across different cloud services via a shell
Safety check
Usable, but read the notes first.
- ●Installer downloads a remote script and pipes it to the shell.
scripts/install.sh
Automated scan of the repo files. Always review code you run.
From the README
Mirage is a Virtual Terminal for AI Agents. The virtual filesystem delivers broad data context, virtualized CLIs give an agent more flexibility on tool use, dynamic runtimes save underlying infrastructure cost and are more token efficient, and fine-grained control over an agent's actions and even over what it can see gives the best security. Together these parts form one virtualized terminal, giving the best agent performance, cost efficiency and security.
Here is an example of launching Mirage inside an application:
ws = Workspace(
{
"/tmp": (RAMVFS(), MountMode.EXEC),
"/redis": (RedisVFS(url=redis_url), MountMode.WRITE),
"/slack": (SlackVFS(SlackConfig(token=slack_bot_token)), MountMode.EXEC),
},
# monty captures python, so scripts run sandboxed inside the workspace
runtimes=[MontyRuntime(captures=["python", "python3"]), "workspace"],
)
# one grep sweeps every source
await ws.shell("grep -rln session /redis /tmp")
# run a script that lives in Slack, file the report into Redis
await ws.shell("python3 /slack/channels/general_.../files/example__F....py > /redis/report.txt")
# install a typed CLI under a head word: dispatched by name, not by path,
# and discoverable through `man`, `type` and `which` like any other program
ws.register_cli("slack", SLACK, {"token": slack_bot_token})
await ws.shell('slack send-message --channel general --text "report is up"')
About
- Unified virtual terminal interface, not N SDKs and M MCPs. Every backend speaks the same filesystem semantics, so pipelines compose across services.
- A virtual filesystem over every source. S3, Google Drive, Slack, Gmail, Redis and the rest mount side by side under one root, so an agent reaches all of them through a unified interface with the unix tools it already knows, like
ls,grep,findandjq. - Virtual command line tools (CLIs).
git,slackandntnare answered by Mirage itself, so an agent drives the service with nothing installed, across different runtimes and machines, and one tool can be virtualized into two or more, each under its own name with its own credentials. - Routed, dynamic runtimes. Python, JavaScript and any other command can be sent to a configured runtime, in process, sandboxed or remote, which decouples computation from storage and lets either change without touching the other.
- The virtualized Mirage shell. It binds the filesystem, the CLIs and the runtimes into one command line, so pipes, redirection, variables, jobs and history work across all three.
- Profiles designed for agents.
allow,askanddenygovern commands and CLIs, whilehideandshowgovern files and folders, so a hidden path is not merely unreadable but absent from the filesystem the agent sees. - A scriptable policy engine. A policy script can prohibit any dangerous action before it runs, and the same stack gates every VFS op and session write, so neither a file nor an environment variable leaks.
- Notifications wired into the VFS and agents. External changes become an event stream on the mount, so a new Slack reply surfaces as a change to the chat file in the virtual filesystem, and the agent reacts to it instead of rescanning the tree.
Virtual Filesystem
Everything Mirage "mounts" as one unified virtual filesystem for AI agents. Each service sits side-by-side under a single root and answers the same POSIX semantics.
| | VFS