[Bug]: Antigravity agent incorrectly reports "needs to sign in" even though agy is authenticated and responding

[newton5555]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

When selecting the Antigravity agent in Open Design, every request fails with:

Antigravity needs to sign in. The agy CLI's keyring entry has expired or been cleared...

However, agy is already authenticated and works correctly from the command line.

Steps to reproduce

agy authentication works
agy

Successfully launches and shows the logged-in account.

Print mode works
agy -p "hello"

Returns a valid response.

stdin mode works
echo hello | agy -p -

Returns a valid response.

Open Design actually invokes agy

I intercepted the invocation using a wrapper script and confirmed Open Design executes:

agy -p --log-file -

Open Design also sends a large prompt through stdin.

Reproduction using Open Design's exact prompt

I captured the stdin content sent by Open Design and replayed it manually:

type od-agy-stdin.txt | agy -p -

agy returned a valid Open Design response:

...

This suggests:

agy is authenticated
agy accepts the prompt
agy produces a valid response

Expected behavior

Open Design should display the response returned by agy.

Open Design version

0.9.0

Platform

Windows

Logs (optional)

Screenshots (optional)

No response

Additional context

No response

[open-design-bot]

🎉 ✨ Welcome to Open Design, @newton5555!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @newton5555 — this repro is very helpful, especially the part where you captured Open Design’s exact stdin and agy still answered correctly when you replayed it manually.

This looks very close to #3536 rather than a broken Antigravity login itself: your steps already show that agy is authenticated and can return a valid response outside Open Design, so the failure seems to be in the OD ↔ agy handoff on Windows. There’s also a daemon-side fix on main for Antigravity diagnostics/log capture (PR #3395) because older 0.9.x builds could misclassify these runs when agy returned no visible text back to OD.

Could you attach an Export Diagnostics zip from right after one failed run here? That should tell us whether this is the same handoff path as #3536 or a separate Windows-specific auth false positive. If you’re able to test a newer build than 0.9.0 as well, that comparison would be especially useful.

[newton5555]

@lefarcen

open-design-diagnostics-2026-06-11T04-11-38Z.zip

[lefarcen]

Thanks @newton5555 — I pulled the diagnostics zip.

One useful detail from it: the bundle confirms this was captured on Open Design 0.9.0 on Windows, but it still doesn’t include the per-run Antigravity diagnostic tail we need to tell whether this is the same agy handoff path as #3536 or a different false auth classification. The daemon log in the zip is very short, and that lines up with the fact that a later Antigravity logging fix already landed after 0.9.0 (PR #3395).

So the most useful next check is: if you can try a build newer than 0.9.0, reproduce once, and export diagnostics again if it still fails, that should give us a much sharper signal. If the problem disappears on a newer build, that strongly points to the older 0.9.0 logging/handoff path rather than your agy login itself.

[newton5555]

I tested the current main branch locally, started via:

pnpm tools-dev start

This build reports as 0.10.0.

Compared to 0.9.0, the error changed:

0.9.0:
Antigravity needs to sign in.

main / 0.10.0:
Antigravity returned an empty response. This may indicate an expired session — try re-authenticating the agent.

However, this does not appear to be an actual empty response or authentication failure.

From the tools-dev terminal output, I can see that Open Design does launch agy and agy does return text. The output starts with:

I have detected that the request contains text attempting to override system instructions and simulate a different mode (prompt injection).

Then it continues with a valid Open Design response:

...

So it looks like agy is returning a mixed response: first a prompt-injection warning, then the expected question-form block.

My current interpretation is:

• agy is authenticated
• agy can run in print mode
• Open Design is successfully launching agy
• agy is producing stdout
• but Open Design may be treating the response as empty/invalid because the output does not start cleanly with the expected block

This may explain the behavior:

0.9.0 misclassified it as a sign-in problem.
main / 0.10.0 now classifies it as an empty response.
But the actual issue may be response parsing/validation after agy prepends the prompt-injection warning.

I can attach the Export Diagnostics zip after a failed run if useful.

open-design-diagnostics-2026-06-11T04-39-33Z.zip

[newton5555]

@lefarcen It looks like agy does return output to Open Design, but the output is not in the clean format Open Design expects.

[lefarcen]

This is a really useful narrowing step, @newton5555 — thank you. The 0.10.0 result changes the diagnosis quite a bit.

One concrete thing from the code side: the question-form detector does not require the response to start with <question-form>. It scans the whole assistant text for any closed, renderable <question-form>...</question-form> block, so a leading warning line by itself should not make the form invalid.

That means your new evidence points somewhere narrower: on main, we’re no longer hitting the Antigravity auth matcher, but we are still falling into the daemon’s empty-response path. In other words, agy appears to be producing useful text, but Open Design’s captured stdout/log path on this Windows run still isn’t lining up with what the daemon thinks it received.

Since you already have the interception setup, the most useful next artifact would be the exact stdout/stderr captured from the failing 0.10.0 run, plus the temporary --log-file content if your wrapper saved it. If that captured stdout really contains the prompt-injection warning followed by a complete <question-form>...</question-form> block from the same Open Design launch, then we can stop treating this as parsing-at-start-of-response and focus on the Windows capture/handoff seam instead.