[Bug]: Antigravity text generation always fails — runtime-created .gemini/.agents dirs trip the "wrote files" guard #29876

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Environment: macOS arm64, T3 Code (Beta) 0.1.60.1.6, Antigravity ACP runtime 1.4.1 (releaseId f9bdd68291ae78c38d2141e63bc86b84e6cc7b9f60f71652c68435a7943deb17).

1. Set the text generation model to antigravity / gemini-3.8-flash (Settings → text generation model).
2. Open any thread that has at least one message.
3. Regenerate its title (thread menu → Regenerate title). Same via MCP: t3_thread_update { "action": "regenerate_title" }.
4. Watch ~/.t3/userdata/logs/server.trace.ndjson.

Deterministic here: 5/5 attempts failed. Nothing changes in the UI — the title stays as-is and no error is surfaced.

Expected behavior

The thread title is regenerated. The exact same operation succeeds when the text generation model is the Pi provider (PiTextGeneration.generateThreadTitle, 2.7 s, 2026-11-02 22:39).

Actual behavior

Every attempt fails after 7–19 s. The only trace is a WARN span in server.trace.ndjson; there is no user-facing error and no thread state change:

TextGenerationError {
  operation: "generateThreadTitle",
  detail: "Antigravity wrote files during text generation."
}

Root cause (verified by polling the scoped temp cwd while the request runs): AntigravityTextGeneration.runJson creates a scoped temp dir t3-antigravity-text-* and, after the prompt completes, asserts fs.readDirectory(cwd).length > 0. But the Antigravity 1.4.1 runtime itself bootstraps skill directories in the project cwd at session start — before any model output:

t=1.05s  t3-antigravity-text-XXXX  files: []
t=3.79s  t3-antigravity-text-XXXX  files: [".agents", ".gemini"]
         .gemini/skills   (empty dir)
         .agents/skills   (empty dir)

So the guard always trips on the runtime's own scaffolding and reports it as a model file write. It is not the model ignoring "do not write files" — the model never writes anything.

This affects every text generation operation routed through the same runner, not just titles: thread title, commit message, PR content, branch name, review guide.

Impact

Major degradation or frequent failure

Version or commit

Desktop Beta 0.1.60.1.6

Environment

macOS arm64, T3 Code (Beta) 0.1.60.1.6, Antigravity ACP 1.4.1, text generation model antigravity / gemini-3.8-flash. Pi text generation works on the same install.

Logs or stack traces

{"type":"effect-span","name":"ThreadTitleRegenerationService.execute","durationMs":7883.9,"attributes":{},"events":[{"name":"[\n  \"Thread title generation failed\",\n  {\n    \"threadId\": \"4905bc80-...\",\n    \"requestId\": \"d5fe6467-...\",\n    \"cause\": {\n      \"_id\": \"Cause\",\n      \"failures\": [\n        {\n          \"_tag\": \"Fail\",\n          \"error\": {\n            \"_tag\": \"TextGenerationError\",\n            \"operation\": \"generateThreadTitle\",\n            \"detail\": \"Antigravity wrote files during text generation.\"\n          }\n        }\n      ]\n    }\n  }\n]","attributes":{"effect.logLevel":"WARN"}}],"exit":{"_tag":"Success"}}

Successful control case on the same install (Pi text generation):

22:39:45 TextGeneration.generateThreadTitle            2673.3 ms
22:39:45 PiTextGeneration.generateThreadTitle          2673.0 ms

Workaround

Set the text generation model to Pi (or any non-Antigravity provider). Title regeneration / commit messages / PR content then work normally.

Suggested fix

Ignore runtime scaffolding in the guard. Options, cheapest first:

1. Only count regular files, not directories (the runtime creates directories only).
2. Whitelist .gemini and .agents entries.
3. Snapshot the cwd right after makeRuntime(cwd) / before the prompt, then diff after completion — catches real model writes while tolerating runtime setup.

Also worth surfacing the failure in the UI: right now the operation silently no-ops from the user's point of view, which makes this look like "the button is broken".