Antigravity integration does not reliably execute CoPet hooks on Windows; native PowerShell bridge works

[zinserjohn]

Environment

Windows 11
CoPet 0.1.11
Antigravity
Antigravity config: ~/.gemini/config/hooks.json

Problem

CoPet’s Antigravity integration installs successfully and writes the expected hook configuration, but on Windows the generated hook execution path does not work reliably end-to-end.

CoPet generates Antigravity commands that invoke the shared copet-hook.sh helper using POSIX shell syntax. On my Windows install, Antigravity either did not deliver lifecycle events to CoPet or tool execution became blocked by hook-launch errors.

The pet itself and CoPet’s runtime are not the issue. I was able to isolate the failure to the Antigravity → hook command boundary.

Verification

With CoPet running, I manually POSTed an event to the endpoint/token written under:

~/.copet/runtime/event-endpoint
~/.copet/runtime/event-token

using:

{
"agent": "antigravity",
"kind": "thinking",
"toolInput": {
"subject": "Manual bridge test"
}
}

CoPet immediately accepted the event, displayed:

Thinking: Manual bridge test

and changed the pet animation to its thinking state.

agent-events.log confirmed:

{
"agent": "antigravity",
"kind": "thinking",
"outcome": "accepted",
"currentState": {
"state": "thinking"
}
}

This confirmed that the CoPet runtime, localhost event server, UI messaging, and pet animation/state handling were all functioning correctly.

Workaround that fixed it

I replaced only the Antigravity hook launch layer with a Windows-native PowerShell helper:

powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File C:\Users<user>.copet\hooks\copet-hook.ps1 antigravity tool.before

The PowerShell helper:

reads Antigravity’s hook JSON from stdin;
extracts tool/tool-input information;
reads CoPet’s current event-endpoint and event-token;
POSTs the normalized event to CoPet;
returns the appropriate JSON to Antigravity ({"decision":"allow"} for blocking lifecycle events).

After switching the four Antigravity lifecycle hooks to this PowerShell bridge, all of them started working:

antigravity tool.before
antigravity tool.after
antigravity user.prompt
antigravity session.stop

CoPet then correctly displayed tool activity and completion, and the pet reacted throughout the task.

Example accepted runtime event:

{
"agent": "antigravity",
"kind": "tool.before",
"tool": "run_command",
"message": {
"text": "Running echo CoPet test"
},
"outcome": "accepted",
"currentState": {
"state": "running"
}
}

Why I think this is Windows-specific

The current CoPet helper is a #!/bin/sh script, and the generated Antigravity command uses POSIX constructs such as:

if [ -f '...' ]; then ...; fi

That execution model seems fragile with Antigravity’s Windows hook runner. Once the same bridge logic was moved behind a native PowerShell command, it worked reliably without any changes to CoPet’s runtime.

Antigravity’s Windows command parser also appears sensitive to quoting. During testing, a quoted PowerShell -File argument was passed through as a path containing literal quote characters:

Processing -File '"C:\Users<user>.copet\hooks\copet-hook.ps1"' failed:
Illegal characters in path.

Removing unnecessary quoting for a path without spaces resolved that particular launch failure.

Expected behavior

Enabling the Antigravity integration in CoPet on Windows should produce a hook command that Windows/Antigravity can execute directly, and PreToolUse, PostToolUse, PostInvocation, and Stop should reliably reach CoPet.

Possible fix

It may be worth giving the Antigravity adapter a Windows-specific hook helper/command rather than routing Windows through the shared POSIX .sh helper. A small PowerShell equivalent of the existing helper was sufficient in my testing.

I’m happy to provide the PowerShell bridge I used if it would be useful for reproducing or implementing the fix.