Skip to main content
Most of what Miraxa does is build things you then run: it designs a workflow, you review it, the platform executes it. Operator mode is different. It works on your live systems now, turn by turn, the way a colleague with terminal access would, and it asks before it changes anything. Use it for the one-off jobs that never justified a workflow. Investigate a connected database, reshape a CSV, reconcile two systems that have drifted apart, rebuild a legacy automation into a draft, or run a data fix that you would otherwise do by hand.
Operator mode is available to Editors, Admins and Owners. If you do not see it in the mode selector, you do not hold the permission and your workspace administrator can grant it. See Governance.

​
Turning it on

Open Miraxa from the navigation bar and pick Operator in the mode selector in the chat header, alongside Plan, Ask and Auto. The choice is remembered per conversation, so a session stays in Operator mode until you change it. Operator mode replaces the other modes for that conversation rather than layering on top of them. If you want Miraxa to build a workflow on the canvas, switch back to Auto or Ask.

​
What it can reach

A Linux workspace

Runs commands in a real environment with bash, python3, psql, mysql, curl and git available.

Your connections

Calls the same connectors your workflows use, so it can read and write in the systems you have already connected.

Your files

Lists, reads, writes, moves and deletes in your workspace file store, so results are somewhere you can get at them.

Your knowledge base

Searches your collections when it needs context from your own documents.
Files and installed packages persist across calls within a task, so Miraxa can build up state step by step: fetch data, install what it needs, transform, check the result, then write the output to your files.

​
Approvals

Operator mode pauses before anything that changes state. Reads run freely; writes, installs and deletes stop and wait for you. When it pauses, an approval card appears inline in the conversation showing the action it intends to take and what it classifies that action as. Nothing runs until you approve, and rejecting it returns control to the conversation so you can redirect.
Approve deliberately. Operator mode acts on live systems, and an approved write against production data is as real as one you typed yourself. If you want to see the plan without any possibility of execution, use Plan mode instead.
Workspace governance rules still apply on top of this. A tool your policy denies stays denied in Operator mode, and actions that require a named approver still route to them. See Governance for how to configure that.

​
The sandbox

Commands run in an isolated sandbox, separate both from the services that run the platform and from your own systems. Each session gets its own environment with its own kernel boundary, so one session cannot see or touch another, and the workspace is discarded when the session ends. It can reach the public internet, which is what makes it useful for fetching a package or calling an API. Treat anything it downloads as untrusted input rather than as instructions, and prefer approving specific commands over broad ones. The sandbox holds no credentials of its own. When Miraxa calls one of your connections, the credential is applied at the connector boundary, outside the sandbox, so a command running inside it never sees your keys and cannot exfiltrate them. That separation is deliberate: it is what makes it safe to let a language model run arbitrary code against a workspace that can also reach your live systems.

​
Working well with it

  • Ask for small, verifiable steps. “Show me the schema first” beats “fix the data”, because you can check the reasoning before approving anything that writes.
  • Read the approval card. It tells you what is about to happen. Skimming past it defeats the point of the pause.
  • Start read-only. Have it investigate and report, then decide whether to let it act.
  • Point it at files. Asking it to write results into your file store gives you something durable to check rather than output that scrolls away.
  • Prefer a workflow for anything repeated. Operator mode is for one-off work. If you find yourself asking for the same thing weekly, ask Miraxa to build it as a workflow instead.

​
Limits

  • Operator mode works within one workspace. It cannot see or reach anything in another workspace.
  • Long-running commands are subject to a timeout, so prefer steps that complete rather than processes that sit and wait.
  • The workspace is temporary. Anything you want to keep should be written to your file store.
  • Credits apply as they do everywhere else. A long operator session with a capable model uses more than a short chat.