[Bug]: Antigravity sessions load no AGENTS.md/GEMINI.md rules (global or workspace), unlike Claude and Codex #15283

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @ycmjason for the canary setup and the runs outside T3, which made this much easier to pin down. The no-T3 acpx results match what the server does on current main (77823bd; your f391794 is an ancestor).

   What's happening

   • T3 doesn't load AGENTS.md or GEMINI.md for any provider, and it doesn't strip them for Antigravity. Claude and Codex sessions see those files because their CLIs discover them.
   • An Antigravity thread runs the official agy_acp_server. ACP has no system-prompt field, so the only text T3 adds is its own orchestration block, wrapped as <t3_code_instructions> on the first user prompt (t3AcpPromptWithInstructions in apps/server/src/provider/T3OrchestrationInstructions.ts). T3 doesn't send _meta.systemPrompt; that's an acpx extension.
   • acpx antigravity exec returning NONE for global rules, workspace AGENTS.md / .agents/, and _meta.systemPrompt.append, while agy -p finds the same files, means agy_acp_server isn't applying rule files. That part is upstream of T3.
   • There's also a T3-side gap for global rules. Each Antigravity instance gets a private profile with GEMINI_HOME pointed at it (apps/server/src/provider/antigravityAuthSupport.ts). The profile links only ~/.gemini/config/skills and ~/.gemini/antigravity-cli/skills back to the real home. ~/.gemini/AGENTS.md, GEMINI.md, and config/rules aren't linked, so even if the ACP server started reading global rules from GEMINI_HOME, it wouldn't see yours. Workspace rules live in the session cwd, so this doesn't explain the workspace canaries.
   • Closed [Feature]: Configurable instruction files injected into the system prompt, per provider and per project #4490 was marked completed, but no provider setting currently reads arbitrary instruction files.

   Likely fix area

   • Upstream: agy_acp_server loading the same rule files agy does.
   • T3 side: linking the global rule files (AGENTS.md, GEMINI.md, config/rules) into the private Antigravity profile, so they'd be picked up once upstream loads them.
   • A T3-side copy of the full loader (global files, the workspace walk, GEMINI.md vs AGENTS.md precedence, .agents/rules triggers) is another option, but it could drift from the CLI and would apply rules twice once the ACP server loads them itself.

   Until then, pasting the rules into the prompt is the workaround. A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   upstream

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026
3. Ashkaan commented on Oct 20, 2026

   

   Ashkaan

   on Oct 20, 2026

   Contributor

   More actions

   Same result on Linux with 0.1.1-nightly.20261019.3348 and agy_acp_server 1.1.1 (the version T3 reports as supported).

   One data point for the T3-side fix above: I put rule files straight into the instance's private profile (GEMINI_HOME/GEMINI.md, AGENTS.md, config/AGENTS.md, config/rules/r.md) and none loaded, so linking them in wouldn't help until the ACP server reads them. Workspace AGENTS.md, GEMINI.md, .agents/AGENTS.md, .agents/rules/ and _agents/rules/ didn't load either, with the folder listed in trusted_workspaces.json.

   The same instruction sent inline in the message was followed every time.
4. t3dotgg commented on Oct 21, 2026

   

   t3dotgg

   on Oct 21, 2026

   Member

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Theo

   Thanks for the report. This fault is outside T3 Code, so we cannot fix it here. Please report it to the project that owns that tool. If you find a fault in T3 Code itself, please open a new issue with steps to reproduce it.
5. t3dotgg

   closed this as not plannedon Oct 21, 2026
6. Gamrix commented on Oct 24, 2026

   

   Gamrix

   on Oct 24, 2026

   Last edited by Gamrix

   More actions

   As a temporary workaround, one can make an antigravity wrapper that injects the system prompt. Here's a Claude description that you can copy paste to make your own:

   The fix is a small proxy that sits between T3 and Google's Antigravity agent and adds your rule files to the first message of every session automatically, so you never paste anything. Both the threads you start and the subagents T3 delegates to get your rules.
   
   Setup (macOS):
   
   	1.	Do a manual install of the Antigravity runtime. Per T3's Antigravity docs, download the archive from the official ACP Registry and extract agy_acp_server and localharness_external into the same folder, at the same version. Copying both files out of ~/.t3/tools/antigravity-acp/ should also work. Don't put the proxy inside that managed folder, since a T3 update can overwrite it.
   	2.	Put the proxy in that same folder and run chmod +x on it. It has to sit next to localharness_external, because T3 refuses a binary path without that file beside it.
   	3.	Change the first line to an absolute Node path. Mac apps launched from the Dock don't get your shell's PATH, so #!/usr/bin/env node may not find a Homebrew or nvm install. Run which node and put the result after #!.
   	4.	Point T3 at it: Settings → Providers → Antigravity → Binary path → the proxy file.
   	5.	Test it: put a canary word in AGENTS.md, start a new T3 thread, and ask without tools whether its instructions contain the word. T3's logs should also show a line like [rules-proxy] injected 3 rule file(s).
   
   What it loads: the same files agy loads on its own:
   
   	•	your global ~/.gemini/AGENTS.md and ~/.gemini/GEMINI.md
   	•	AGENTS.md, GEMINI.md, and .agents/ files in each folder from the repo root down to the session's folder
   	•	.agents/rules/*.md files marked always_on
   
   It also falls back to CLAUDE.md in any folder with no AGENTS.md. If AGENTS.md is a symlink to CLAUDE.md, it reads the file once, not twice.
   
   I tested it against a mock ACP agent, not the real Antigravity server, so the canary test in step 5 is the real check.
   
   Caveats:
   
   	•	It adds the rules once per session, on the first message. In very long threads, Antigravity may compress older context and lose detail from them. If you notice that, change EVERY_TURN near the top of the file to true. That re-sends the rules with every message, at a token cost.
   	•	With a manual install, you update the Antigravity runtime yourself.
   	•	This is the same fix the bug report proposes T3 make. Opening a PR on #15283 would retire the proxy once it lands.
   
7. Silent-wqh commented on Oct 29, 2026

   

   Silent-wqh

   on Oct 29, 2026

   More actions

   Root Cause Analysis (Reverse-Engineered from agy_acp_server & localharness_external v1.3.0)

   I traced the full call chain across T3 Code (AntigravityInstallation / antigravityAuthSupport), agy_acp_server, and the Go harness binary (localharness_external) to see why agy -p loads AGENTS.md / GEMINI.md while agy_acp_server does not.

   1. Why localharness_external skips AGENTS.md and GEMINI.md

   Inside localharness_external, localagent_executor.CreateAgentExecutorOpts initializes the customization manager (customizations.NewManager) using field #28 (rules_config) of the HarnessConfig protobuf (antigravity.localharness.RulesConfig):

   // localagent_executor.go -> CreateAgentExecutorOpts.func1
   custOpts.MarkdownRuleFilenames = opts.HarnessConfig.GetRulesConfig().GetFilenames()

   In customizations.(*Manager).getRules and discoverRulesForDir, there are two distinct discovery paths:

   1. Subdirectory rules (discoverPathsForScope): Scans <workspace>/.agents/rules/*.md (plus .agent/rules/*.md, _agents/rules/*.md) and $GEMINI_HOME/config/rules/*.md. This path does not depend on MarkdownRuleFilenames.
   2. Standalone root/hierarchical files (visitParentCustomizationFiles & readGlobalRules): Walks from cwd up to the git root looking for standalone rule files, and checks $GEMINI_HOME/<filename> for global rules. Both functions loop over m.opts.MarkdownRuleFilenames.

   2. The bug in agy_acp_server

   In agy_acp_server, both LocalConnectionStrategy._build_harness_config() (google/antigravity/connections/local/local_connection.py) and ProxyConnectionStrategy._build_harness_config() (google3/cloud/developer_experience/antigravity_extensions/acp_server/proxy_agent_config.py) build localharness_pb2.HarnessConfig over the WebSocket InitializeConversationEvent, but neither populates harness_config.rules_config.filenames.

   Because rules_config.filenames arrives at localharness_external as an empty list [], visitParentCustomizationFiles and readGlobalRules are complete no-ops—so project AGENTS.md / GEMINI.md and global $GEMINI_HOME/{AGENTS,GEMINI}.md are never read.

   ---

   How to Fix agy_acp_server Directly (True <user_rules> System Prompt Injection)

   Instead of wrapping the binary to prepend rules into the first user message (which can get compacted away in long sessions and doesn't support subagents or native rule frontmatter/@import), you can patch _build_harness_config() in agy_acp_server so localharness_external loads GEMINI.md and AGENTS.md natively into the <user_rules> system prompt section:

   if not harness_config.rules_config.filenames:
     harness_config.rules_config.filenames.extend(("GEMINI.md", "AGENTS.md"))

   Adding those two lines in:

   • google3/cloud/developer_experience/antigravity_extensions/acp_server/proxy_agent_config.py (ProxyConnectionStrategy._build_harness_config, used for oauth-personal / oauth-business)
   • google/antigravity/connections/local/local_connection.py (LocalConnectionStrategy._build_harness_config, used for API key / Vertex and base config)

   immediately restores native AGENTS.md and GEMINI.md discovery (including git-root parent traversal and subagent inheritance).

   Applying the patch without breaking T3 Code's managed runtime check

   Note that T3 Code's AntigravityInstallation.completedRelease checks that agy_acp_server matches the exact byte size recorded in .install-complete.json (Number(info.value.size) === record.executable.bytes), though it does not re-verify SHA-256 after initial download:

   • On macOS / Linux (agy_acp_server.par): .par is a standard zipapp archive. After patching proxy_agent_config.py and local_connection.py inside the zip, either update executable.bytes in ~/.t3/tools/antigravity-acp/<platform>-<arch>/versions/<sha256>/.install-complete.json or pad a comment/zip comment to keep the exact byte size.
   • On Windows (agy_acp_server.exe): It is a PyInstaller onefile binary where PYZ.pyz (cflag=0) and the CArchive TOC are stored uncompressed. You can recompile both modules using the binary's own bundled python310.dll, trim a docstring so the zlib-compressed entry fits inside the original slot, pad with \x00 to the original slot length, and keep the .exe at the exact original byte size (81,437,336 bytes on 1.3.0 win32-x64).

   Remaining T3-side improvement for Global Rules

   As noted in the triage comment above, T3 Code isolates GEMINI_HOME to <userdata>/providers/antigravity/<hash> and currently only symlinks config/skills and antigravity-cli/skills in linkAntigravityUserSkills (apps/server/src/provider/antigravityAuthSupport.ts). If linkAntigravityUserSkills also links ~/.gemini/AGENTS.md, ~/.gemini/GEMINI.md, and ~/.gemini/config/rules into the profile directory, global rules will work automatically as well.