[Bug]: Open Design fails with "Antigravity returned an empty response" while local agy CLI works

[solomon-cc]

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 running Open Design, it fails with an AGENT_EXECUTION_FAILED error, stating that Antigravity returned an empty response. However, my local agy CLI is working perfectly fine and authenticated. Re-authenticating the agent did not resolve the issue for Open Design.

Steps to reproduce

1. Ensure local agy CLI is authenticated and working (e.g., running agy status or similar commands works fine).
2. Trigger the Open Design run.
3. Observe the AGENT_EXECUTION_FAILED error.

Expected behavior

Open Design should be able to communicate with the Antigravity agent successfully since the local session/CLI is valid.

Open Design version

0.12.0

Platform

Windows

Logs (optional)

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

Open Design run error diagnostics
trace_id: a3904cb9-8234-4b2d-bdfc-37a08291173e
run_id: a3904cb9-8234-4b2d-bdfc-37a08291173e
error_code: AGENT_EXECUTION_FAILED
project_id: 9dd8ff92-587b-47b7-bc98-f89e70f35672
conversation_id: 5aa1dcb7-97c5-4aed-bbda-b50f586e9512
assistant_message_id: 72150835-ed93-428c-b5f0-c3ae9428af97
agent_id: antigravity

Screenshots (optional)

Additional context

[open-design-bot]

🎉 ✨ Welcome to Open Design, @solomon-cc!

✨ 🔥 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 @solomon-cc — thanks for including the trace id and the screenshots; that makes this much easier to narrow down.

This looks close to the existing Antigravity bug family in #4121 rather than a plain expired-login case. In the daemon, Open Design talks to Antigravity through agy print/stdin mode (agy -p -), so a healthy interactive agy session by itself doesn't fully rule out the OD ↔ agy handoff path. We also already shipped earlier Antigravity fixes for diagnostic capture and JSONL parsing (#3395 and #4247), so seeing the same empty response symptom on 0.12.0 suggests either agy still isn't producing usable stdout/log data in print mode on this machine, or there's another Antigravity-specific handoff/parsing case.

Could you attach an Export Diagnostics zip from right after one failed run, plus the output of agy --version and one simple stdin-mode check on the same machine (for example echo hello | agy -p -, or the PowerShell equivalent)? That should tell us pretty quickly whether this belongs with the existing #4121 / upstream agy hang track, or whether 0.12.0 has a new OD-side regression.

[solomon-cc]

Hey @solomon-cc — thanks for including the trace id and the screenshots; that makes this much easier to narrow down.

This looks close to the existing Antigravity bug family in #4121 rather than a plain expired-login case. In the daemon, Open Design talks to Antigravity through agy print/stdin mode (agy -p -), so a healthy interactive agy session by itself doesn't fully rule out the OD ↔ agy handoff path. We also already shipped earlier Antigravity fixes for diagnostic capture and JSONL parsing (#3395 and #4247), so seeing the same empty response symptom on 0.12.0 suggests either agy still isn't producing usable stdout/log data in print mode on this machine, or there's another Antigravity-specific handoff/parsing case.

Could you attach an Export Diagnostics zip from right after one failed run, plus the output of agy --version and one simple stdin-mode check on the same machine (for example echo hello | agy -p -, or the PowerShell equivalent)? That should tell us pretty quickly whether this belongs with the existing #4121 / upstream agy hang track, or whether 0.12.0 has a new OD-side regression.

[lefarcen]

Thanks — those screenshots are already useful.

They confirm two important things on this machine: agy --version is returning normally, and a simple stdin-mode run is producing output outside Open Design. That makes this look less like a plain expired session and more like the narrower OD ↔ Antigravity handoff / response-handling seam we were worried about.

The main missing artifact now is the Export Diagnostics zip from right after one failed Open Design run. Once we have that, we should be able to tell whether OD is seeing genuinely empty stdout/log output from agy, or whether agy is returning something that OD is failing to classify/render correctly.

[Maou3434]

I did a bit more investigation on this and wanted to share what I found.

I don't have the antigravity-cli source (only the compiled agy.exe), so I can't confirm the exact implementation, but I was able to reproduce some behavior that may help narrow this down.

Observations

Running agy --print interactively works as expected.

However, when I redirect stdout:

agy --print "hello" > output.txt 2>&1

the output still appears on the terminal, while output.txt remains empty.

Since both stdout and stderr are redirected, I would normally expect the response to end up in output.txt. Instead, it appears to bypass the redirected streams entirely.

This also lines up with the behavior seen from Open Design, where the daemon launches agy as a subprocess and captures stdout, but receives an empty response even though the process exits successfully.

Hypothesis

Based on the behavior above, my current hypothesis is that agy --print is writing through a terminal-specific output path rather than the redirected stdout stream (for example via the terminal/TUI stack). If that's the case, it would explain why it works in an interactive terminal but returns an empty stdout when run in a headless or subprocess environment.

If this hypothesis is correct, --print should ideally write directly to stdout (fd 1) when stdout is redirected or when running without an attached TTY, rather than relying on terminal-specific rendering.

Hopefully this helps narrow down whether the issue is in the OD ↔ agy handoff or in how agy emits its final response.

[lefarcen]

One small but useful detail from the daemon side: on this failure path, Open Design does try to read the tail of Antigravity’s log file before it falls back to the generic empty-response/auth message.

So the diagnostics export is the key missing piece here — if agy is writing a useful tail, it should show up there; if the log is empty or missing in the failed run, that points us at a different seam. Once you attach that zip from immediately after a failed run, we can narrow this down much more confidently.

[lefarcen]

Hey @om0852 — this is a strong narrowing step, thank you.

Your diagnosis matches the current daemon code path: in the silent-empty-output branch, Antigravity still had a special fallback that could promote a no-signal exit into AGENT_AUTH_REQUIRED, even when the log/stdout didn't actually contain auth text. So the direction you outlined — keep quota/auth classification only when the content supports it, and otherwise fall back to AGENT_EXECUTION_FAILED — is the right fix for the false expired-session message.

Heads-up: PR #4893 is already open against this same seam and touches the same daemon/tests area, including apps/daemon/src/server.ts and apps/daemon/tests/chat-route.test.ts. Rather than opening a second PR from scratch, the highest-value next step would be to compare your Windows repro and reasoning against #4893 there. If your local fix is narrower/cleaner, or if it covers a case that PR misses, adding that review context on the PR would be very useful.

[lefarcen]

Quick sync for @solomon-cc: the implementation track is now active in PR #4893, and @om0852 has already added the Windows repro + comparison notes there.

At the moment the ball is with reviewers on that PR, so this issue can stay focused on user-visible symptoms while the code-path fix is being tightened on the PR side. We’ll keep this issue open until PR #4893 lands (or until the PR proves the remaining symptom is entirely upstream to agy).

[github-actions]

This issue has been inactive for 30 days and is being marked as stale. If it is still relevant, please leave a comment or push an update — otherwise it will be closed in 7 days.

This is only a queue-management step, not a rejection of the report. Closed issues can be reopened when work resumes.

[lefarcen]

Hey @Maou3434 — this is a genuinely useful data point.

The stdout-redirection behavior you captured lines up with the same symptom family we've been seeing from Open Design: agy appears to produce visible terminal output in interactive use, but a subprocess/stdout-capture path can still end up with an empty result. That makes your hypothesis — that agy --print may be going through a terminal-oriented rendering path instead of writing cleanly to redirected stdout — a plausible explanation for why OD sees a successful exit with no usable output.

That also fits the current implementation track in PR #4893: the PR is focused on making OD classify this failure more honestly instead of misreporting it as an expired Antigravity session. We’re keeping this issue open while that PR is still under review, and your redirection repro remains useful evidence that part of the remaining behavior may be upstream to agy rather than the OD handoff alone.