Gemini Full Access Is Not a macOS Permission

Gemini Full Access Is Not a macOS Permission

There is a hidden settings toggle in Google's Gemini desktop app that nobody has officially announced. It sits under the computer-use section, it is not live, and Google has not confirmed it exists. It is also the most consequential thing I have seen in a Mac settings pane this year, mostly because of the name it implies.

BleepingComputer reported on 3 October that Gemini on macOS could soon read, create, modify or delete files anywhere on the machine, reach apps like Mail, Safari and Messages, and stop asking for permission on every step. The screenshot behind that story shows the setting: Additional sandbox options. Its description, quoted from the app itself:

By enabling additional sandbox options, you will be able to expand what Gemini can do and access on your Mac. Depending on which settings you enable, Gemini may be permitted to take actions without asking for your permission first.

Nothing is confirmed. Do not go looking for the toggle tonight expecting to find it. But the design decision is already legible in the wording, and I think the interesting part of this story is not the capability. It is the label.

The boundary that exists today is a folder list

Start from what Google actually ships. The live Gemini desktop documentation describes the current macOS app in plain terms: you share screen context by pressing both Command keys, you dictate into any app, and you connect local folders so Gemini Spark can organise and synthesise your files. That last clause is the whole contract. Spark, which Google calls its 24/7 personal AI agent, is scoped to the folders you hand it.

In June, when Spark landed on macOS in beta for Google AI Ultra subscribers, Google made the same promise in its own words: "Gemini Spark only has access to the files you give it permission to use." Google also flagged that you will eventually be able to assign Spark multi-step tasks from your phone and let them run on your Mac while you are away.

So we have a folder-scoped agent today, and a plan to make it reachable remotely. The hidden toggle is the third piece: something that lets the scope stop being a folder list.

Three things called roughly "access"

Here is where the naming gets dangerous, and it is a different problem from the capability itself.

Full Disk Access is a real macOS grant. It is a TCC entry, kTCCServiceSystemPolicyAllFiles, and it is the thing that lets an app read mail, messages and browser history. On 2 October Apple announced it will add "additional controls" so that granting this level of access requires "very explicit user action" — and said plainly that "as AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially." I wrote about that announcement here, including why the boundary that actually matters lives inside the app holding the grant rather than in the toggle itself.

Full Access is what TestingCatalog says the Gemini setting is called in practice, and it is an app-level intent, not an operating-system permission. It does not map one-to-one onto anything in System Settings. It has to resolve to some combination of what the app already holds.

Connected folders is the boundary Google documents today, and it is a user choice, revocable by disconnecting the folder.

Three different concepts, two of them sharing a name. When the marketing and the settings UI both say "Full Access", a user who goes to System Settings to check what they just granted is looking at the wrong list. And the wrong list is worse than no list, because it produces a false all-clear.

The confirmation list is keyed to commerce

Both write-ups are careful to note that Gemini would still stop and ask before doing anything expensive or legally binding: buying a product, transferring money, creating an online account, accepting legal terms on your behalf, or changing sensitive information about you.

Read that list next to the capability list — read, create, modify, delete any file anywhere, act across applications — and the mismatch is the actual story. Every item on the confirmation list is an outward-facing commercial or legal act. None of them is a local destructive act. Overwriting a config file is not buying a product. Rewriting your shell profile is not accepting legal terms. An approval dialog written in the vocabulary of commerce is the wrong key for a capability whose blast radius is your disk.

Google is clearly working on the model side too. In its Gemini 4 Argon announcement, Google says it is "deploying misalignment mitigations that monitor Argon's chain-of-thought and actions and stop execution when necessary", and that it is hardening sandboxed environments by isolating and sealing them before high-risk runs. That is the right instinct, and it is also a control that acts in time rather than after the fact. A monitor that halts a run cannot restore the file the run already replaced.

The pre-flight backup is the tell

The detail I keep coming back to is from the earlier TestingCatalog report, in August, on the first traces of computer-use code in the app. Alongside the expected controls — a mini-view of the active screen, a "Task" option in the prompt bar, a guard against the Mac sleeping mid-task — there was an optional safety feature that automatically backs up selected folders to Google Drive before a task begins. TestingCatalog's own objection was practical: if a selected folder holds hundreds of gigabytes, that upload is slow and eats your storage before the task can start.

But the design problem is deeper than bandwidth. A pre-flight backup defines safety as the set of folders you remembered to select. Everything outside that set is the blast radius, silently. And the copy lands in someone else's cloud, which means the mitigation for local destruction is a remote copy you now have to trust and pay for.

The instinct is right. Git already does this for code. The implementation is what I would push back on.

Take the snapshot yourself

If you want a restore point before you hand a desktop agent the wheel, do it locally and make it verifiable. This is the whole thing:

#!/usr/bin/env bash
# agent-preflight.sh - take a verifiable local snapshot before you let a desktop
# AI agent (Gemini Full Access, Claude Cowork, anything) write to your workspace.
#
# Usage:  ./agent-preflight.sh [workspace-path]
#         ./agent-preflight.sh --restore <snapshot-dir> <workspace-path>
#
# No network. No uploads. macOS bash 3.2 compatible.

set -eu

die() { printf '%s\n' "$*" >&2; exit 1; }

sha256_of() {
  if command -v shasum >/dev/null 2>&1; then
    shasum -a 256 "$1" | cut -d' ' -f1
  else
    sha256sum "$1" | cut -d' ' -f1
  fi
}

# macOS and GNU tar disagree about the archive-exclude flag spelling.
tar_exclude() {
  if tar --version 2>/dev/null | grep -q GNU; then
    printf -- '--exclude=%s' "$1"
  else
    printf -- '--exclude' "$1"
  fi
}

if [ "${1:-}" = "--restore" ]; then
  [ $# -eq 3 ] || die "usage: $0 --restore <snapshot-dir> <workspace-path>"
  snap="${2%/}"; dest="$3"
  [ -f "$snap/workspace.tar.gz" ] || die "no workspace.tar.gz in $snap"
  mkdir -p "$dest" || die "cannot create $dest"
  printf 'Restoring %s into %s\n' "$snap" "$dest"
  tar -xzf "$snap/workspace.tar.gz" -C "$dest"
  printf 'Done. Expected archive checksum:\n  %s\n' "$(cut -d' ' -f1 < "$snap/workspace.tar.gz.sha256")"
  exit 0
fi

target="${1:-$PWD}"
[ -d "$target" ] || die "not a directory: $target"

target_abs=$(cd "$target" && pwd)
case "$target_abs" in
  /|"$HOME") die "refusing to snapshot $target_abs" ;;
esac

stamp=$(date +%Y%m%d-%H%M%S)
snap="$target_abs/.agent-preflight/$stamp"
mkdir -p "$snap" || die "cannot create $snap"

printf 'Target : %s\n' "$target_abs"
printf 'Snapshot: %s\n' "$snap"

# 1. Compressed archive. Keep .git: history is exactly what a runaway agent edits.
tar -czf "$snap/workspace.tar.gz" \
    $(tar_exclude '.agent-preflight') \
    -C "$target_abs" .

# 2. Checksum, so "the archive is intact" is a fact and not a hope.
sha256_of "$snap/workspace.tar.gz" > "$snap/workspace.tar.gz.sha256"

# 3. Prove the archive actually reads back before we tell anyone it is safe.
if ! tar -tzf "$snap/workspace.tar.gz" >/dev/null 2>&1; then
  die "archive failed read-back verification; treat this as NOT safe"
fi

entries=$(tar -tzf "$snap/workspace.tar.gz" | wc -l | tr -d ' ')

# 4. If it is a git repo, also take a real bundle - cheaper to restore than tar.
if git -C "$target_abs" rev-parse --git-dir >/dev/null 2>&1; then
  head_sha=$(git -C "$target_abs" rev-parse --short HEAD 2>/dev/null || echo "none")
  git -C "$target_abs" bundle create "$snap/repo.bundle" --all >/dev/null 2>&1 \
    && printf 'Git bundle: repo.bundle (HEAD %s)\n' "$head_sha" \
    || printf 'Git bundle: skipped (could not create)\n'
fi

printf 'Entries : %s\n' "$entries"
printf 'Checksum: %s\n' "$(cat "$snap/workspace.tar.gz.sha256")"
printf '\nRestore with:\n  %s --restore %s %s\n' "$0" "$snap" "$target_abs"

Three things in there are deliberate. It refuses to run against your home directory or /, because a mistake there should be loud, not quiet. It reads the archive back before reporting success, so a truncated tarball cannot masquerade as a safety net. And when the workspace is a git repo it also writes a bundle, because restoring history is a different operation from restoring files.

I ran this against a plain directory and a git repo, then corrupted a file and restored it, and confirmed the printed checksum matches the archive on disk. That is the bar: the restore point is a fact, not a hope.

What is not true yet

Let me be precise about the uncertainty, because the coverage has been loose about it.

The setting is hidden. Google has not confirmed it, has not announced a rollout date, and BleepingComputer notes it is unclear "which Gemini model will power it". TestingCatalog is equally careful: the capability is "currently associated with trusted testing", and its presence there "does not provide a reliable launch timeline". TestingCatalog also notes that Gemini 4 Argon — announced 30 September, rolling out first to trusted cyber defenders through Google's Fairwind program — is being evaluated for computer use, but that Google has not confirmed any connection between Argon and what is appearing in the desktop app. Treat that as a plausible guess, not a roadmap.

What is real is the direction of travel, and it is worth noticing that the two platforms are moving at once. Apple is tightening the OS grant. Google is building an app-level way around needing it. Neither has published a mechanism, a version, or a date.

What to do this week

Do not wait for the toggle, because most of the value here is available today.

Snapshot before you grant anything. The script above, git commit plus a git bundle, or a plain tar. Whatever you pick, restoring must be something you have tested, not assumed.

Know which grant you are holding. Read the Full Disk Access audit approach — query the TCC access table for kTCCServiceSystemPolicyAllFiles and read the client column. If the answer surprises you, that is the finding.

Do not treat "it asked me first" as a control. The confirmation list is about spending money and accepting terms. Your files are not on it.

Watch for the naming. The day a toggle labelled Full Access ships, the first question worth asking is which macOS permission it maps onto. If the answer is "several", then revoking any one of them changes nothing, and your audit story has to name which grant did what.

Sources

• BleepingComputer: Google Gemini could soon get full access to your Mac's files, apps and the web
• TestingCatalog: Gemini desktop to get broader Computer Use permissions
• TestingCatalog: Google tests Computer Use on Gemini Desktop
• Google: Gemini Spark updates: macOS launch, connected apps and more
• Google: Gemini 4 Argon: our next era of frontier intelligence
• Google: Gemini for desktop
• MacRumors: Apple Announces 'Full Disk Access' Changes on macOS Due to AI Agents