Approval fatigue: permissions for agents you trust

A problem we had ourselves.

Luminair is built inside Luminair, usually with several sessions running at once on different parts of the code. Clicking “approve” in six panes is not a workflow anyone keeps up for long, which is why the app took the no-popup route early. The comment at the top of the sandbox code in desktop/main.js says it plainly: “Luminair runs Claude in bypassPermissions, no approval popups. That's speed with no walls.”

Everything in this post is about that last phrase. If you take the prompts away, you owe the user something better than trust. The fixes described below were written in Luminair sessions, and Solace commits carry a Claude co-author line in git.

Luminair · three sessions side by side

The prompt that trains you to click yes.

The default safety model for coding agents has been simple: before the agent runs a command or edits a file, it asks. That sounds careful. The trouble is volume. A real task can fire dozens of requests, almost all of them harmless, and a person who sees “run the tests?” twenty times in a row starts approving on reflex.

Anthropic named this in October 2025, when it added sandboxing to Claude Code. Constantly clicking approve, it wrote, “can lead to ‘approval fatigue’, where users might not pay close attention to what they're approving, and in turn making development less safe.” Its answer was a fence at the operating-system level, for files and for the network, and it reported that “sandboxing safely reduces permission prompts by 84%” in internal use.

In March 2026 it went further. The post on how Claude Code auto mode was built opens with the number that frames this whole debate: “Claude Code users approve 93% of permission prompts.” Auto mode hands those decisions to model-based classifiers, which the post calls “a middle ground between manual review and no guardrails.”

In August, Help Net Security reported that auto mode would become the default for new sessions on Pro, Max and Team plans from 14 August. It relayed Anthropic's study of 1,053 paid testers, in which “human review caught just 13.6% of dangerous commands, while auto mode caught 89%.” The same report adds the honest caveat that auto mode “does not eliminate” risk, because it relies on AI to judge what is safe.

Ask only at the wall.

Luminair took the third column in Fig 01. There are no per-action popups at all. Instead there are two things a prompt never gave you: a wall the agent physically cannot cross, and a way back.

The fence

Type /sandbox in any session to open The Sandbox. The sheet describes itself as “a fence around the agent”: the run still goes full speed with no popups, but it cannot write outside the folders you allow or reach a website you have not allowed. Per session you can pick Default, Protected or Unfenced. Protected fences the run to the session's own folder, with everything else read-only and localhost allowed.

It is off by default. Briefly, from the end of August, Protected Mode was switched on for every account except the owner's; on 10 September that was reversed, and it became opt-in per session, or forced on by a Team policy. We mention it because defaults are the whole argument of this post, and we changed ours.

When a fenced run does hit the wall, you get the one question that is worth asking. A card titled Protected Mode names the blocked folder and offers three buttons: Allow once, Always for this session and Deny. The code comment above that card calls it “the end of approve-everything vs allow-everything”. It grants the folder, not the single file, and its buttons lock after one choice.

A fence is only as good as the engine

Luminair drives many engines, and they do not all support the same fence. Rather than pretend, a single file, desktop/lib/execution-policy.js, decides per engine what Protected Mode really means on each turn (added 7 September 2026):

The rule that matters is the refusal. If you pinned protection on, a quiet downgrade to an open run would be worse than no feature at all:

function assertCliPolicy(engine, sandbox, platform = process.platform) {
  const v = verdict(engine, sandbox, platform);
  if (v.mode === 'unfenced' && sandbox.required) {
    throw new Error('Protected Mode is required for this session but ' + v.reason +
      '. Use the built-in Claude engine, or turn protection off ' +
      'for this session under /sandbox.');
  }
  return v;
}

The way back

The second replacement for prompts is //rewind, which shipped with Harness v1 on 29 August 2026. Before every turn, typed on the Mac or sent from the phone, Luminair snapshots the project folder, including what shell commands later touch. //rewind opens the timeline, shows what changed since any snapshot, and restores the folder to that moment. Restoring is itself snapshotted first, so you can rewind the rewind. The command's own help text ends: “This is the undo button approval prompts never gave you.”

The supervisor gets one switch.

Walls cover what an agent may touch. They say nothing about whether its work is actually done. That is the job of the Solace, or MC. It keeps a ledger of what you asked for and moves each item from open to working to done as runs stream and finish. It can send a fresh, read-only AI to trace a finished feature through the code and pass or fail its wiring. Its done-enforcement gate means “tested” needs real evidence, and only you can mark an item “confirmed”.

Notice the shape. Approval prompts ask you before every step. MC asks you once, after, about the result, which is the part you can actually judge.

The switch itself went through a quick lesson. On 25 July 2026 the first build put a “Session Controller” on/off switch in the sidebar. The same afternoon, a second commit removed the per-session Controller toggle that sat on every pane's title bar, along with the switch and blinking dot in the sidebar, and left one small MC chip next to the header's // button. The commit message gives the reason in one line: “The Session Controller is ONE global switch, not per-session.”

That is the approval-fatigue lesson again, applied to our own UI. A control repeated on every pane is a control you stop looking at, and it hides the real question, which is simply “is the supervisor on?”. One chip answers it at a glance. The panel behind it then lists each MC feature with what it costs (some spend tokens, some are free) and lets you turn features off individually. A feature only runs when the master switch is on too.

Trusted inside a scope.

A supervisor that can approve things is itself something to secure. On 31 August 2026 a commit titled “Harden Solace authority boundaries” went through MC's powers one by one and removed every place where it could act more widely than the user had agreed to. A follow-up on 7 September locked its review runs down further.

Two of these are worth a closer look.

Adopted rules. For the workspace admin, MC writes a daily report after 5pm with improvement suggestions, and the admin can adopt one as a standing rule that binds every future desktop and phone turn. That is real authority, so the path is narrow. Before anything is saved, the text is checked against a deny pattern for phrases like “bypass security”, “grant shell” or “upload credentials”, and a match is refused on the spot. If it passes, a sheet titled Adopt an absolute MC rule? spells out that the rule “cannot grant tools, permissions, credentials, or weaken security”. Only rules stamped as approved locally, from the daily review, for all sessions, are loaded back at launch.

The tool list that was not a lock. A comment in desktop/main.js, dated 21 July, records a finding from the SDK docs: under bypassPermissions, an allowed-tools list is a no-op, because bypass approves every tool before the list is consulted. A real lockdown needs dontAsk, where listed tools are pre-approved and every other tool is denied. MC's reviewers now run that way, with an extra check that refuses any read outside the workspace, even through a symlink.

Set your walls in two minutes.

1. 1In a session, type /sandbox (a single slash). Choose Protected under This session to fence that session to its own folder, or turn the Fence on and list extra writable folders and reachable websites.
2. 2Type //doctor. Its Protected Mode (sandbox) check, in the Security group, lists which of your engines enforce the fence and which would run unfenced.
3. 3If a turn went wrong, type //rewind, pick the snapshot from before it, look at what changed, and restore.
4. 4On Pro+, the Solace chip sits in the header. Flip its switch to turn Solace on; click the name to see each feature and turn parts off.

Checked, and not claimed.

Sources

• Anthropic Engineering · 20 October 2025Making Claude Code more secure and autonomous with sandboxing
• Anthropic Engineering · 25 March 2026How we built Claude Code auto mode: a safer way to skip permissions
• Help Net Security · 10 August 2026Anthropic to put AI in charge of reviewing Claude Code actions by default