fix(deps): bump google-antigravity to 0.1.8 to clear a Defender false positive on the bundled harness [PILOT-7463]

[Mihaiii]

Issue

PILOT-7463

Summary

• Bump the antigravity extra from google-antigravity==0.1.7 to ==0.1.8, relock.
• 0.1.7's bundled localharness.exe trips a Windows Defender false positive (Misleading:Win32/Malgent) that blocks execution, so every antigravity agent start on the Windows eval slice dies with [WinError 225] ... the file contains a virus or potentially unwanted software. coder_eval_uipath builds 13287452 / 13288171: 0/7 windows tasks each.
• The false positive is specific to 0.1.7's build — 0.1.8 and 0.1.16 launch clean, repeatedly, on the same Defender that quarantines 0.1.7.
• No AV exclusion is available on the eval's Windows image: the agent is elevated and Add-MpPreference still fails with 0x800106ba (Defender config is centrally managed there), so the pin is the only lever.

Why the log said something else

The SDK retries agent start 4x. Attempts 1-3 fail at subprocess.Popen with WinError 225; Defender quarantines the exe in the meantime, so attempt 4 raises Could not find default localharness binary — and that is the message the run reports. It points at path/PATH discovery instead of an AV block, which is what makes this bug read as a packaging problem. Read the first agent-start traceback, not the last.

glibc gate

pyproject.toml requires verifying the bundled ELF before bumping, since the manylinux_2_17 tag is not a reliable floor. Checked with pyelftools against the published Linux wheels:

version	DT_RELR	max GLIBC symbol	linkage
0.1.7 (current)	none	GLIBC_2.26	dynamic, 7 DT_NEEDED
0.1.8 (this PR)	none	GLIBC_2.26	dynamic, same 7 DT_NEEDED
0.1.16	none	(none)	fully static, no PT_INTERP

0.1.8 is identical to the current pin, so it loads on Ubuntu 22.04 (glibc 2.35). The note now records that, plus the fact that 0.1.16+ ships a static binary (hence its added musllinux tag), which retires the check.

Testing

• tests/test_antigravity_agent.py: 66 passed with the extra installed, so the three real-SDK importorskip tests actually executed against 0.1.8.
• SDK surface this repo touches, verified present and behaviour-identical on 0.1.8: LocalAgentConfig kwargs (incl. env, its None default and round-trip), hooks.policy.{allow_all,workspace_only}, types.{ThinkingLevel,GeminiAPIEndpoint,GeminiModelOptions,UsageMetadata,Step*}, Conversation.{send,receive_steps,wait_for_idle,wait_for_wakeup}.
• ruff format --check and ruff check clean.

0.1.8 over 0.1.16 deliberately: the harness binary is a dominant non-model driver of eval results, so this takes the smallest step off the bad build. 0.1.16 passes every check above too, if you'd rather take the newer one.

Follow-ups

• coder_eval_uipath branch fix/antigravity-windows carries a self-retiring stopgap that pins 0.1.8 forward on the Windows slice only — it compares the installed pin against 0.1.7 and turns itself off once this ships.
• Submit 0.1.7's localharness.exe to Microsoft as a false positive.
• Pre-existing, unrelated to this bump: the ThinkingLevel mirror at src/coder_eval/models/agent_config.py:317 is Literal["minimal","low","medium","high"], but the SDK enum has a fifth value extra_high (identical on 0.1.7/0.1.8/0.1.16). thinking_level: extra_high is rejected with a Pydantic literal_error, so the top reasoning level is unreachable through coder_eval.

[github-actions]

Claude finished @Mihaiii's task in 1m 20s —— View job

---

PR Review in Progress

Todo List:

• Read .github/code_review.md for review standards
• Review git diff origin/main...HEAD
• Read full pyproject.toml for context
• Read full uv.lock changes
• Check cross-file consistency
• Perform "what's missing" analysis
• Provide structured review feedback

[CarlesUIPath]

Approve, trivial bump. Some follow-ups my agent review caught for doc hygiene easily actionable:

1. docs/agents/ANTIGRAVITY.md:30 still says "pinned to 0.1.7" — stale after this bump.
2. The glibc/ELF floor in the pin comment is verified manually, not in CI. Worth a small opt-in smoke job (install .[antigravity] on the 22.04 target + import, or a scripted readelf -d | grep RELR assertion) so the floor is machine-enforced — and a pin↔doc parity lint rule would stop the doc drifting again.

[Mihaiii]

@CarlesUIPath

"docs/agents/ANTIGRAVITY.md:30 still says "pinned to 0.1.7" — stale after this bump." - addressed in 7b2154d , thanks!

I do have a nightly pipeline run here (stopped after a few minutes), except I changed the code in coder_eval_uipath to install the desired version due to coder_eval needing a new version release with this fix so that was a workaround to arrive to the same desired Antigravity version and check it works.