◉ANTIGRAVITY LABJP
Articles/Antigravity Basics
◉ Antigravity Basics/2026-08-26Intermediate

Redrawing Your Workspace Boundary Now That Review Mode Auto-Approves Reads

Antigravity CLI 1.1.20 made in-workspace reads auto-approved in review mode. Here is what I found when I actually counted what became readable across two real working trees.

antigravity461antigravity-cli14security22workspace11

✦ Premium Article

One line in the Antigravity CLI 1.1.20 release notes says that in the default review mode, read access inside the workspace is now granted automatically. Confirmations for edits and external access stay exactly as they were. Only reads and listings go quiet.

That is a welcome change. As an indie developer running a lot of small projects, I was clicking through approval dialogs dozens of times a day, and clicking had stopped being a decision. It had become a reflex.

Then I stopped, because I could not answer a simple question: what is actually inside my workspace? While I was approving reads one at a time, every path was shown to me before it was opened. Once that stops, the judgment has to happen earlier — once, up front, when you decide what the workspace even is.

So I counted. Two working trees, mechanically. The numbers did not match what I had pictured.

The workspace is not what git shows you

I started with an ordinary Node project: npm init, four direct dependencies (express, typescript, axios, ws), and a .gitignore holding node_modules/, .env*, and dist/. Nothing unusual.

MeasureValue
Files on disk1,352
Files tracked by git3
Packages installed79
Size of node_modules38 MB

Four direct dependencies pulled in 79 packages transitively. Git tracks three files: package.json, package-lock.json, and .gitignore.

This is the part that is easy to gloss over. .gitignore decides what version control sees. It does not stop anything from reading the filesystem. A file that disappeared from git's view is still sitting right there on disk, and read auto-approval looks at the disk.

"My secrets are gitignored, so I'm fine" is a correct statement about commit accidents and a meaningless one about reads.

I have written about the opposite direction — agent output silently swallowed by .gitignore — in a pre-commit detection gate for files that vanish into .gitignore. This article is about files git cannot see but anything else can read.

99.7% of the readable surface was code I never wrote

I re-counted the same tree, splitting it into dependency and build directories (node_modules, dist, .next, Pods, .venv, and friends) versus everything else.

CategoryFilesShare
Files I put there40.3%
Dependencies and build output1,34899.7%

Almost the entire readable surface was code I had not written a line of. By extension: 441 .js files, 292 .ts, 193 source maps, 144 Markdown files. Markdown and LICENSE files inside node_modules alone accounted for 220.

None of that is dangerous on its own. Reading dependencies is a normal and useful thing for an agent to do. What struck me was how far off my mental model was. When I read "read access inside the workspace," I pictured my source code. The actual set of files that could be opened without a prompt was more than three hundred times larger.

There is a practical consequence too. Once dependencies are excluded, the inventory drops from 1,352 files to 4. Taking inventory is not about reviewing everything — it starts by separating what you own from what you merely have on disk.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
✦You will be able to measure what your agent can now read without asking, using numbers from your own working tree instead of assumptions
✦You will be able to find credentials sitting inside the agent's read surface and move them out before anything goes wrong
✦You will understand why name-based scanning misfires, and how a two-stage inventory cuts what you have to eyeball by roughly ten times
Secure payment via Stripe · Cancel anytime
✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $15 for lifetime access
View Membership →

Related Articles

◉ Antigravity2026-08-23
Choosing a Remote Control Host Machine Comes Down to Daemon Lifetime and Revocation Paths
What to settle before you flip on Remote Control in Antigravity 2.0: how the headless daemon behaves per OS, why there are two separate sign-out paths, and how to inventory the read surface on a candidate host machine.
◉ Antigravity2026-10-03
Start Your Antigravity Deny List From Your Own Shell History
Before you let an agent drive your terminal, decide the first commands for the Deny list by counting your own shell history. A short script, a three-box sorting table, and a throwaway-repo test to confirm the rules actually bite.
◉ Antigravity2026-09-15
When an agent ends without a reason, I check the page's character encoding first
A page handed to ReadURL can end an Antigravity agent with nothing but Agent execution terminated. Here is how I tell those pages apart before handing them over, and why I now fetch and re-encode first.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links