Modes & Royal Mode

Royal Mode

Royal mode gives the agent full autonomy and full machine access — no approval prompts, no destructive-command floor. It’s the most powerful mode, so it’s the most carefully gated.

Enable/royal or the mode dropdownConsentone-time, per workspace

What Royal mode changes

Compared to Auto mode, Royal removes the last guardrails:

  • No permission prompts — every edit and command runs as issued.
  • No destructive-command floor — force-push, history rewrites, and broad deletes are allowed.
  • Access isn’t confined to your workspace.

“Royal mode means no approval prompts, not no limits” — it’s still bounded by token, time, and iteration budgets, and a no-progress detector stops runaway loops.

The consent gate

The first time you switch a workspace into Royal mode, LakshX shows a warning dialog explaining the power you’re handing over. You confirm with:

dialog
I understandenable Royal mode

Consent is remembered per workspace, so you approve once per project. Declining reverts you to the previous mode. Because the gate lives in the IDE — not in the agent — a prompt injection can’t auto-enable Royal mode on your behalf.

Only in a repo you can afford to lose

Royal mode can do anything you can do at a terminal, including irreversible git operations and deletes outside the workspace. Use it on projects under version control that you’re prepared to reset, and prefer a non-production machine.

The safety net it keeps

Royal isn’t a blind free-for-all. Two protections stay on:

  • Append-only audit log — every action Royal takes is recorded machine-wide, and Royal can’t erase its own audit or checkpoint storage.
  • Checkpoints & undo — LakshX still checkpoints before mutations, so workspace changes remain reversible (see Checkpoints & Undo). Note that undo covers your workspace, not edits Royal makes outside it.

Royal Mode 2.0 — coming

A phased, self-verifying architecture for Royal mode is designed and in progress. It wraps the run in an explicit state machine — plan → execute → verify → fix— where the agent can’t declare a task done until the harness re-runs a frozen verification spec (build, tests, browser checks, and a fresh-context critic) server-side. This is documented as designed, not yet shipped as the default loop.

Available today vs. coming

Royal mode itself — autonomy, the consent gate, the audit log, and checkpoints — ships today. The phased verification state machine (Royal Mode 2.0) is a designed, staged upgrade.