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.
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:
I understand — enable Royal modeConsent 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
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
