Before Your Finger Learns the Approval Dialog: Folding Antigravity Permissions Into One Policy

Classify by reversibility and auth cost

Never decide whether to approve based on an operation's name. The same "file write" carries wildly different weight for output to a temp directory versus overwriting a deploy config.

I look at operations along two axes. One is reversibility: can it be undone, is undoing costly, or is it impossible. The other is auth cost: does the operation use external credentials, and does failure lead to charges or public exposure.

I collapse those two axes into four tiers.

The value of this split is that passing read and reversible automatically narrows approvals down to genuinely heavy operations. When the total count of approvals drops, the weight of each one returns.

I turn the classification itself into code: a function that takes an operation and returns a tier.

// permission/classify.ts
export type Tier = "read" | "reversible" | "remote" | "irreversible";
 
export interface Operation {
  kind: "fs" | "shell" | "git" | "http";
  action: string;      // e.g. "write", "delete", "push", "POST"
  target: string;      // e.g. path, URL, remote name
}
 
// Operations that cannot be undone, or lead to charges/publishing
function isIrreversible(op: Operation): boolean {
  if (op.kind === "fs" && op.action === "delete") return true;
  if (op.kind === "git" && op.action === "push" && /--force/.test(op.target)) return true;
  if (op.kind === "http" && op.action === "POST" && /\/(billing|charge|publish)/.test(op.target)) return true;
  return false;
}
 
// Operations with external effect
function isRemote(op: Operation): boolean {
  if (op.kind === "git" && op.action === "push") return true;
  if (op.kind === "http" && op.action !== "GET") return true;
  if (op.kind === "shell" && /\b(deploy|wrangler|gcloud)\b/.test(op.target)) return true;
  return false;
}
 
// Locally undoable changes
function isReversible(op: Operation): boolean {
  if (op.kind === "fs" && op.action === "write") return true;   // temp or source writes
  if (op.kind === "git" && ["add", "commit"].includes(op.action)) return true;
  return false;
}
 
export function classify(op: Operation): Tier {
  if (isIrreversible(op)) return "irreversible";
  if (isRemote(op)) return "remote";
  if (isReversible(op)) return "reversible";
  return "read";
}

The key is deciding by property, not by name. A git push rises to irreversible when --force is present, while an ordinary push stays at remote. Your definition of danger differs from mine, so this classifier is exactly the part you grow by hand.

Fold scattered permissions into one policy

Once tiers are set, all that remains is declaring, in one policy, whether each tier returns auto-allow, approval, or denial. This becomes the single home for settings that used to live in three separate systems.

// permission/policy.ts
import { classify, type Operation, type Tier } from "./classify";
 
export type Decision = "allow" | "prompt" | "deny";
 
// Deny-leaning default. Loosen only the tiers you name (deny by default)
const POLICY: Record<Tier, Decision> = {
  read: "allow",
  reversible: "allow",
  remote: "prompt",
  irreversible: "deny",   // operations done only by hand are blocked from the start
};
 
// Explicit overrides. Reading this alone tells you what is treated specially
const OVERRIDES: Array<{ match: (op: Operation) => boolean; decision: Decision }> = [
  // Deploys to a verification staging target are loosened to approval
  { match: (op) => op.kind === "shell" && /wrangler deploy --env staging/.test(op.target), decision: "prompt" },
  // The live billing API is always denied regardless of tier
  { match: (op) => op.kind === "http" && /\/billing\/live/.test(op.target), decision: "deny" },
];
 
export function decide(op: Operation): { tier: Tier; decision: Decision } {
  const tier = classify(op);
  for (const rule of OVERRIDES) {
    if (rule.match(op)) return { tier, decision: rule.decision };
  }
  return { tier, decision: POLICY[tier] };
}

The aim of this shape is that the whole of your judgment fits on one screen. Per-tier defaults gather in POLICY, special cases in OVERRIDES. Back when I edited per-MCP allowlists individually, just understanding "what am I currently allowing where" took minutes. After consolidation, reading these two objects is enough.

The migration steps are as follows. I cleared mine in a single day, in this order.

1. Export existing approval logs and MCP allowlists to surface what you actually permit
2. Run each operation through classify and count how many fall into each tier
3. Move operations that land in read and reversible to auto-allow. Most approvals vanish here
4. Review only the remaining remote and irreversible operations, one by one, in OVERRIDES
5. Rewrite the unified permission settings so they match this policy's output

The thinking behind MCP least privilege itself belongs to MCP tool allowlist least-privilege design, but from the consolidation angle it helps to see it not as "deleting the allowlist" but as "folding it into the input side of one policy."

In my setup, this consolidation dropped the daily total of approvals and authentications from over 40 to around 12. All 12 that remain are remote or higher, meaning approvals genuinely worth reading. With the count down, the habit of weighing content came back.

Reduce auth prompts from the operation side

Separate from approvals, what wore me down was OAuth re-authentication. When you are asked to authenticate every time you switch sessions, that too becomes something you wave through.

In 2.2.1, refreshed tokens are saved automatically into the OS keyring. To reliably benefit, I also handle tokens through the keyring in my own tooling. Not placing credentials in a process environment variable as plain text is both a fatigue countermeasure and a basic defense for credentials.

// permission/token-store.ts
import { execFile } from "node:child_process";
import { promisify } from "node:util";
const run = promisify(execFile);
 
// Using the macOS keychain as an example, defer tokens to the OS credential store
const SERVICE = "antigravity-lab";
 
export async function saveToken(account: string, token: string): Promise<void> {
  // Delete before adding to avoid duplicate entries on overwrite
  await run("security", ["delete-generic-password", "-s", SERVICE, "-a", account]).catch(() => {});
  await run("security", ["add-generic-password", "-s", SERVICE, "-a", account, "-w", token]);
}
 
export async function loadToken(account: string): Promise<string | null> {
  try {
    const { stdout } = await run("security", ["find-generic-password", "-s", SERVICE, "-a", account, "-w"]);
    return stdout.trim();
  } catch {
    return null;   // if unsaved, return null and let the caller start the auth flow
  }
}

Deferring to the keyring narrows re-auth to only when a token has actually expired. In my case, this dropped auth prompts from a dozen-odd per week to a handful. With the count lower, when I am occasionally asked to authenticate, there is room to ask "why now."

On Linux secret-tool plays the same role, and on Windows the Credential Manager does. The design is simply moving the lifetime management of credentials from the app to the OS.

Stop the quiet return of allow-everything

Consolidation is not a one-time job. In operation, there will always come a moment when you want to add an exception to OVERRIDES for an annoying approval. Stack up those one-liners and the policy scatters again.

To prevent that quiet regrowth, I always drop decisions into an audit log and review it just once a week.

// permission/audit.ts
import { appendFile } from "node:fs/promises";
import { decide } from "./policy";
import type { Operation } from "./classify";
 
export async function guarded(op: Operation): Promise<Operation> {
  const { tier, decision } = decide(op);
  const line = JSON.stringify({
    ts: new Date().toISOString(),
    kind: op.kind, action: op.action, target: op.target,
    tier, decision,
  });
  await appendFile("permission-audit.log", line + "\n");
  if (decision === "deny") throw new Error(`denied: ${op.kind}:${op.action} ${op.target}`);
  return op;   // prompt/allow pass to the caller's approval flow
}

At the weekly review I look at a single ratio: the share of the log that is prompt plus deny. If it keeps falling, that is a sign you have added too many exceptions and drifted toward auto-allow.

# Tally the tier breakdown of the recent log
grep -o '"decision":"[a-z]*"' permission-audit.log | sort | uniq -c

When that ratio drops below 10 percent, I wipe OVERRIDES clean and rebuild from the tiers. The goal was never to reduce the number of approvals; it was to keep a state where I can put attention only on heavy operations. Precisely when the number looks too good, I suspect over-loosening.

For the approval flow itself and for handling repeating approval dialogs, reading Fixing repeating command approval dialogs alongside this lets you tighten both the UI side and the policy side.

Wrapping up

Approval fatigue is not weakness of will; it is a symptom of permission being scattered. As a next step, export one day of approval and auth logs, run them through classify, and count each tier. The moment you see how much of your approval budget read and reversible were eating, the payoff of consolidation is nearly certain.

I am still refining this operation myself. The wider the range you delegate to agents, the less permission design is something you build once and leave alone. I plan to keep tightening it while watching the numbers. I hope it helps with your own implementation, and thank you for reading.