Antigravity is a loop. Its agent edits files, runs terminal commands, reads the output, and decides what to do next. So why aren’t your API tests in that loop? They sit in Apidog behind a GUI and run when someone remembers to click. The agent never touches them.
The fix is one config block. The Apidog CLI is an npm package, apidog-cli, that runs the test scenarios you built in Apidog straight from a terminal. Once the CLI is installed and Antigravity knows it exists, the agent runs an Apidog scenario the same way it runs your unit tests: fire the command, read the exit code, fix the code if it is red.
If you have not installed the CLI yet, do that first. How to install the Apidog CLI with an AI coding agent walks through the npm install, authentication, and the first run, with the agent doing the typing. This article assumes apidog --version prints a number and your Apidog account is authenticated.
Which Antigravity this is about
Antigravity is Google’s agentic development platform, built on Gemini 3, that launched in late 2025. It runs the agent through an Agent Manager that plans work, edits files across your repository, and executes shell commands in its own terminal and browser. The agent is the primary surface, and it operates directly on your local machine. If you have opened Antigravity, kicked off a task, and watched the agent run commands and report back, you are in the right place. For the wider tour, see what Google Antigravity is and how to use it.
The distinction matters because Antigravity has its own way of learning project rules, and that mechanism turns a one-off “run my tests” into something the agent reaches for on its own.
Step 1: Give Antigravity a rules file
Antigravity recognizes a special .agents/ directory at your workspace root. Google’s own codelab on building autonomous developer pipelines in Antigravity shows the agent natively picking up files you place there, and workspace rules live in .agents/rules/. Put your project rules in a file like .agents/rules/apidog.md. Antigravity also reads a plain AGENTS.md at the workspace root as a cross-tool foundation, the same file Codex reads for the Apidog CLI; if you already keep one, add the Apidog block there instead of maintaining two.
Put a short Apidog block in that rules file. Something like this:
## API testing with the Apidog CLI
- To test the API, run the Apidog scenario, do not click through the GUI.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- Exit code 0 means every assertion passed. Non-zero means a failure; open the report and fix the code.
- The machine is already authenticated via `apidog login`. Never add an --access-token flag and never put a token in this file.
This is why you write the CLI into the rules file instead of mentioning it in chat. Antigravity does not remember what you teach it between sessions; close the window, reopen it, and the coaching is gone. A scenario ID typed into chat disappears when the session ends. One written into your rules file is there for every teammate and every Antigravity run from now on.
Step 2: Get the command from Apidog
You do not have to guess the scenario and environment IDs. Open the test scenario in Apidog, go to its CI/CD tab, and copy the generated command. It looks like this:
apidog run -t 123456 -e 789012 -r cli
The -t flag is the test scenario ID, -e is the environment ID, and -r cli selects the reporter that prints results inline. Paste those real IDs into your .agents/rules/apidog.md block so the agent runs the exact command Apidog gave you. For every flag, see the apidog run command reference.
Step 3: Have the agent run the test
With the block in place, start a task in Antigravity. The agent loads your rules as it begins, so it already knows the CLI is there. Make a change that touches your API, or just ask it to run the check:
Run the Apidog test scenario and tell me the exit code.
The agent issues the apidog run command from your rules file in its own terminal. Whether it runs without asking depends on your permission setting. Antigravity’s Security Preset determines whether terminal commands and file accesses are reviewed by you before the agent acts, as described in Google’s getting started with Antigravity codelab. If the preset asks for review, approve the apidog run command when it prompts; a read-only test scenario against staging is exactly the kind of safe, in-workspace command that is fine to approve. If you have set the agent to proceed on its own, it runs the command and reports back without stopping.
You want to see the run executing and the agent reporting both the summary and the exit code, not a paraphrase.
Step 4: Read the report inside Antigravity
When a run goes red, the report has the answer. With -r cli, the agent gets a readable breakdown in its terminal: each request, each assertion, and which one failed with expected versus actual value. The failing assertion names the exact field or status code, which is usually enough for the agent to find the fix.
For a report you can open in a browser or hand to a teammate, add the HTML reporter:
apidog run -t 123456 -e 789012 -r cli,html
The html reporter writes a self-contained file to ./apidog-reports. Keep cli in the list so the agent still gets the inline output it reads to decide its next step. For the full set of reporters, including the JUnit format CI dashboards parse, see the complete Apidog CLI guide and how to read Apidog CLI test reports.
Antigravity testing inside its own loop
The point is what happens when you stop asking and the agent runs the scenario on its own because the rules file told it to.
Picture the agent editing a handler that builds a checkout response. Its loop changes. It edits the code, then, instead of declaring victory, runs your Apidog scenario against staging, reads the exit code, and acts on it. Green, it moves on. Red, it opens the report, reads which assertion failed (the status code, the missing field, the wrong value), tries a fix, and re-runs. The API test becomes part of the same edit-test-fix loop the agent already runs your unit tests through. You wrote one instruction and the agent folded the command into how it already works.
This is the delegate-then-verify model that makes any agent workflow safe. Antigravity runs the command and reads the result; you keep authoring scenarios visually in Apidog and spot-check that the agent reads exit codes honestly. For the broader pattern, see how to use AI agents for API testing and the Apidog AI test harness.
Verify Antigravity is actually running the CLI
Agents report success they did not earn, and Antigravity is no exception. Three checks, in order of how often they catch problems.
First, confirm the command ran at all. Antigravity shows the commands it executed and their output in its terminal. Look for the literal apidog run ... line and a result under it. If the agent says it ran the tests but you do not see the command, it summarized something it never did. Ask it to run again and show raw output.
Second, confirm the exit code, the one that matters. Ask directly:
What was the exit code of that apidog run command?
apidog run exits 0 when every assertion passes and non-zero when anything fails. That single behavior lets the agent, or a pipeline, treat the run as a clean gate. When the agent’s prose says “tests passed” but the exit code is non-zero, the exit code is right.
Third, confirm it used the real scenario. If a run fails with “scenario not found,” the agent may have invented or misremembered an ID. Re-check the -t and -e values against your rules file and the command Apidog generated in the CI/CD tab. The IDs in your rules file are the truth.
Optional: connect the Apidog MCP server
Running apidog run from your rules file covers most of what you need. To go further, connect an MCP server.
Antigravity supports the Model Context Protocol, and its MCP servers are configured in the $HOME/.gemini/config/mcp_config.json file, per Google’s getting started codelab. You add a server as an entry in that file’s mcpServers object with its command, args, and env, then refresh MCP in the Antigravity settings. The Apidog MCP server exposes your API specifications over MCP, so the agent can read your schema while it writes code, not just after the fact. The CLI runs the tests; MCP feeds the agent the spec.
When Antigravity gets it wrong
A few failures show up often during setup.
It ignores the rules file. If the agent runs a generic command or none at all, the rules may not be loading. Confirm the file is named correctly and sits where Antigravity expects it for your workspace, then start a fresh task so it re-reads the rules.
It passes an access token anyway. If the agent tries to add --access-token, it is guessing from public examples. Your rules block already tells it not to, since the machine is authenticated via apidog login. Reinforce the line, and never put a real token in the rules file. For how authentication actually works, see Apidog CLI authentication.
It invents a flag. An “unknown option” error means the agent guessed a flag your version does not have. Tell it to run apidog run --help and copy the exact flag from there, which is always correct for your installed version.
It reports a pass on a failed run. The costliest one, and the reason the exit-code rule is in your rules file and your verification step. When the summary and the exit code disagree, the exit code wins.
From a daily agent to a tested loop
That is the setup. Install apidog-cli once following the install guide, add a short Apidog block to your Antigravity rules file, and the agent knows how to run your API tests and read the result inside the same loop it already uses to edit code. A broken endpoint gets caught while the agent is still working on the change, not after it ships.
A test behind a GUI runs when a human clicks; a one-line command runs whenever Antigravity decides to. You keep building scenarios visually in Apidog, and your agent runs them where you are not watching. Download Apidog, build one scenario, drop its apidog run command into your rules file, and watch the agent pick it up on the next change. When you are ready to run the same command in a pipeline without the agent present, Apidog CLI in GitHub Actions covers the secrets, reporters, and exit-code gating.
