agy --print / -p silently drops stdout when run with a non-TTY (pipe, subprocess, redirect)

[rdfitted]

agy --print / -p silently drops stdout when run with a non-TTY (pipe, subprocess, redirect)

Summary

When agy is invoked in headless print mode from a non-TTY stdout context (e.g. piped, redirected to a file, or spawned as a subprocess from another tool), the binary completes a full model round trip but emits no output on stdout — exit code 0, no stderr indicator. Output appears only when stdout is attached to a real terminal.

This breaks every automation / orchestration scenario that wraps agy as a sub-process (CI scripts, agentic frameworks, multi-agent CLIs, IDE integrations, etc.) — the caller cannot distinguish "model returned nothing" from "model returned a useful answer that was silently discarded."

Environment

• Antigravity CLI: 1.0.0 (agy --version)
• OS: Windows 11 (Build 26200.8457)
• Shells tested: Git Bash (MSYS), PowerShell 7, cmd.exe, winpty agy …
• Account: signed in to Antigravity, confirmed working (interactive prompts return output normally)
• Model: Gemini 3.1 Pro (High) (set in ~/.gemini/antigravity-cli/settings.json)
• Verbosity: low

Reproduction

From any shell where stdout is NOT a TTY:

agy --dangerously-skip-permissions -p "Reply with the word PONG only"

Observed:

• Exit code 0
• ~6 seconds wall clock (confirms a real LLM round trip occurred)
• Zero bytes on stdout
• Zero bytes on stderr

The same command in an interactive terminal (Warp, Windows Terminal, PowerShell ISE) returns PONG as expected.

Variants tried — all silently empty:

# Long-form print flag
agy --dangerously-skip-permissions --print "Reply PONG"

# Explicit timeout
agy --print-timeout 30s --dangerously-skip-permissions -p "Reply PONG"

# Redirect to file (rules out pipe-buffering)
agy --dangerously-skip-permissions -p "Reply PONG" > out.txt 2> err.txt
# out.txt and err.txt are both 0 bytes

# Via cmd.exe wrapper
cmd.exe /c "agy --dangerously-skip-permissions -p \"Reply PONG\""

# Via winpty (fails earlier because winpty itself needs a TTY)
winpty agy --dangerously-skip-permissions -p "Reply PONG"
# → stdin is not a tty (exit 1)

# Via PowerShell Start-Process with redirected streams
Start-Process -FilePath "agy" -ArgumentList "--dangerously-skip-permissions","-p","Reply PONG" `
              -RedirectStandardOutput out.txt -RedirectStandardError err.txt -Wait -NoNewWindow
# Hangs indefinitely (3+ minutes, no progress)

What the log shows

~/.gemini/antigravity-cli/cli.log shows the print-mode invocations starting the language server, completing auth, and exiting cleanly — there is no error or warning corresponding to the dropped output.

Expected behavior

agy -p / --print should:

1. Write the model response to stdout regardless of whether stdout is a TTY, OR
2. Provide a --no-tty, --json, or --output <path> flag that guarantees output is captured in non-interactive contexts, AND
3. Emit a clear error to stderr if a non-TTY context is unsupported, rather than exiting 0 with empty output.

Compare to gemini-cli (the deprecated predecessor) which exposed -o text and printed reliably to stdout in any context — this is the headless contract orchestration tools depend on.

Impact

This is a hard blocker for using agy inside any agentic framework or CI pipeline. We migrated ~10 multi-agent orchestration commands from gemini-cli to agy (per the deprecation announcement) and discovered every command silently produces empty results when the orchestrator captures agy's stdout. We are rolling back to gemini-cli until a non-TTY headless mode ships.

Suggested fix

• Flush stdout unconditionally in print mode regardless of TTY detection, OR
• Add --output <path> to write the response to a file, OR
• Add a --format json mode that emits structured output to stdout, decoupled from terminal rendering.

Workarounds we considered

• ConPTY wrapper (e.g. pywinpty) — requires writing a wrapper, defeats the convenience of a CLI.
• Run agy inside a real terminal via scheduled task — too brittle for synchronous orchestration.
• Tail cli.log for the response — log doesn't contain model output, only operational events.

None of these are acceptable for production multi-agent use.

---

Happy to provide additional diagnostics, log excerpts, or a minimal repro repo if useful.

[c3nx]

Confirming on macOS 14 + agy 1.0.1 — presents as an indefinite hang, and --print-timeout doesn't bound it

Same issue on macOS, but instead of empty-exit-0 it hangs forever:

• First -p call after idle returns normally (~7s); every subsequent call hangs indefinitely, including a trivial -p "Reply with OK". Killed after 17 min.
• --print-timeout is non-functional — passing 230s (and 45s) didn't end the wait; the process ran until external SIGTERM. Hung-run logs contain only the Raising signal 15 line, never a turn-complete.
• Likely compounded by UX/Quota Regression: Pro Plan hits daily request limit after only 2 prompts in agy vs 1000+ changes in gemini-cli #56 (quota exhaustion surfacing as a silent hang in -p rather than the interactive Individual quota reached error).

[m061i6]

Confirming this is still present on agy 1.0.1 (Windows 11, Git for Windows / MSYS2 bash) — not fixed in the 1.0.0 → 1.0.1 bump. Environment is a standard mingw64/MSYS2 layout (which agy searches /c/Users/<me>/bin:/mingw64/bin:…), same shell family as the OP.

Controlled TTY vs non-TTY comparison (the variable the thread was missing):

stdout context	Result
Pure interactive PowerShell 7.6.1 console, no redirection	agy -p "What's 2+2? Reply with just the digit." → prints 4 ✅
Same binary, stdout captured (2>&1, | Out-String, or spawned as subprocess)	0 bytes ❌

Single variable: whether stdout is a TTY. This is reproducible across multiple independent cold-start sessions (first prompt of each session), so it is not quota-related — it confirms the output path itself is fine and the regression is purely an isatty() gate on the emission path.

Beyond the OP's matrix I also tried NO_COLOR=1 and TERM=dumb — no change, which rules out color/terminal-capability suppression and points back at the same gate.

Platform note: on Windows this surfaces as empty-exit-0, not the indefinite hang reported on macOS — likely the same emission gate manifesting differently per platform, worth distinguishing during triage.

Scope: for orchestrated / headless callers (my case: an agentic orchestrator that spawns agy as a subprocess) there is no "just attach a TTY" escape hatch — stdout is captured by construction, so the bug is 100% reproducible with zero workaround for this entire class of usage. We've fallen back to the local Gemini CLI for headless review and keep agy to interactive IDE use only.

A --output <path> (newline-terminated, no terminal render/control codes) or --format json flag would fully unblock us.

+1 — hard blocker for headless/orchestration use.

[Nafjan]

Adding a data point for anyone hitting this from an orchestrator/subprocess: I tried wrapping agy in a real ConPTY, and it doesn't help.

Setup matches the other 1.0.1 reports here. Windows 11, native exe at %LOCALAPPDATA%\agy\bin\agy.exe, called from a Python subprocess (stdin=DEVNULL, stdout=PIPE) inside an agent-skill dispatcher. Symptoms match the OP: rc=0, 0 bytes on stdout. --log-file shows full auth, a real streamGenerateContent call, and text_drip.go ... Drip stopped: lastStepIdx=2, charIdx=4, length=4, so the model did answer. The bytes just never reach the pipe.

Then I re-spawned agy under pywinpty 3.0.3 (real ConPTY, 200×40). It does emit something (~838 bytes in my repro), but it's not the response. Under a PTY, agy takes a different code path: it starts loading MCP servers and setting xterm window titles (\x1b]0;npm exec mcp-remote …\x07 for each one), and 90 seconds in it still hadn't finished init, let alone produced an answer. The agy -p you get with a real PTY isn't the same code path as agy -p to a pipe, so allocating one isn't a workaround for headless callers, it just gets you into a different broken state.

So for headless agy on Windows there's no out-of-process fix today. I've fallen back to the Gemini CLI for my gemini-backed sub-agents while this is open. The --output or --format json/stream-json flag already suggested would unblock this.

[Deltaporto]

Adding a WSL/Linux data point from agy 1.0.2: this still affects headless/orchestrated use and presents as an intermittent hang, not just empty stdout.

Environment:

• WSL Ubuntu, non-TTY shell/subprocess use
• agy --version: 1.0.2
• Binary: ~/.local/bin/agy
• App data: ~/.gemini/antigravity-cli
• Auth: consumer OAuth; logs show successful keyring auth in some runs

Minimal repro patterns observed:

printf 'Responda apenas OK.\n' | agy --print --print-timeout 30s

and from Python:

subprocess.run(
    ["agy", "--print", "--print-timeout", "30s"],
    input="Responda apenas OK.\n",
    text=True,
    capture_output=True,
    timeout=40,
)

Observed behavior:

• Some runs succeed and print OK.
• Repeated runs often hang until killed by the external Python/shell timeout.
• --print-timeout 30s does not reliably bound the run; the parent process timeout is what terminates it.
• This is not just a missing-auth case. Logs from successful startup include:

ChainedAuth: authenticated via keyring (effective: keyring)
OAuth: authenticated successfully
Print mode: silent auth succeeded

• In hung runs, logs reach print mode startup and keyring auth, then never produce a turn-complete/output before external SIGTERM.

Integration notes:

• We verified that agy should not be treated like the legacy gemini CLI: no --model, --output-format, or --extensions flags.
• We also found prompts sent through stdin need a trailing newline for more reliable behavior.
• Even after those integration fixes, agy --print remains unstable for non-TTY/headless callers.

Impact: this blocks replacing legacy gemini CLI in a Flask/worker pipeline that invokes the model from Python subprocesses. We are keeping agy opt-in only and retaining the legacy CLI as the default until --print is reliable in non-TTY/subprocess contexts.

A machine-readable output mode (--format json, stream-json, or --output <path>) plus a hard timeout that is enforced outside the renderer would make this usable for orchestrators.

[MarcosNahuel]

+1 — confirmed still present in agy v1.0.2 on Windows 11

Same bug, fully reproducible on the latest release (agy --version → 1.0.2). The v1.0.2 changelog mentions a timeout fix for subagents but does not address the underlying non-TTY stdout flush.

Environment

• Antigravity CLI: 1.0.2
• OS: Windows 11 Home (10.0.26200)
• Shell tested: Git Bash (MSYS), PowerShell 5.1
• Account: signed in (silent auth succeeds, log shows successful daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent calls)
• Invoked as a subprocess from another CLI (Claude Code) via a plugin wrapper

Reproduction (3 variants, all silently empty)

# 1) Git Bash, long elaborate prompt, 60s timeout
"/c/Users/.../agy.exe" --print --dangerously-skip-permissions --print-timeout 60s \
  "Reply with the single word: pong. Do not use any tools."
# → exit 0, stdout 0 bytes, stderr 0 bytes

# 2) Git Bash, minimal prompt, 120s timeout
agy.exe --print --dangerously-skip-permissions --print-timeout 120s "pong"
# → exit 0, stdout 0 bytes

# 3) PowerShell with explicit Out-String capture
$out = & agy.exe --print --dangerously-skip-permissions --print-timeout 60s "pong" 2>&1 | Out-String
# → $out is empty, $LASTEXITCODE = 0

Smoking gun — response IS generated, just not flushed

Unlike the v1.0.0 reports above (which logged a clean exit), v1.0.2 leaves clear evidence in ~/.gemini/antigravity-cli/log/cli-*.log that the full response was streamed internally:

http_helpers.go:182  URL: https://daily-cloudcode-pa.googleapis.com/.../streamGenerateContent
text_drip.go:173     Drip stopped: lastStepIdx=23,  charIdx=48,  length=164
text_drip.go:173     Drip stopped: lastStepIdx=25,  charIdx=151, length=151
text_drip.go:173     Drip stopped: lastStepIdx=27,  charIdx=48,  length=124
...
text_drip.go:173     Drip stopped: lastStepIdx=41,  charIdx=2483, length=2504   ← 2.5 KB of generated text
manager.go:450       CLI store manager shutting down

So text_drip produces 2504 characters of model output across 41 step indices — but stdout receives zero bytes. Confirms the bug is in the drip→stdout bridge in --print mode when stdout is not a terminal, not in model generation or auth.

Impact

This breaks the entire "agy as a subprocess from another tool" use case — exactly the pattern Google promoted for Antigravity's multi-agent workflows. Any wrapper plugin (Claude Code plugins, IDE extensions, CI runners, n8n nodes, agentic orchestrators) that invokes agy --print and parses stdout will silently produce empty results, indistinguishable from "model declined to answer."

Proposed minimal fix

If --print is the documented headless mode, it should io.Copy the text_drip buffer to os.Stdout (or write the final accumulated response once) before manager.go shuts down — regardless of isatty(stdout). A --output <path> or --json flag would be a robust additional escape hatch for orchestration scenarios.

Happy to provide full log files / strace-equivalent traces if useful.

[iwata-1116]

Cross-posting the same comment on #187 for additional context — apologies for the noise.

Adding a workaround and a diagnostic angle that complements this report and #76.

Response is fully persisted on disk — only stdout writeback fails

On the same setup (Windows 11, agy.exe 1.0.2, non-interactive PowerShell parent), the response is silently written to a per-conversation transcript file. Stdout writeback fails, but the model output itself is intact and recoverable.

Run with --log-file to confirm generation completed:

text_drip.go:173] Drip stopped: lastStepIdx=3, charIdx=8, length=8

length=N matches the response character count exactly. In my trace the prompt Reply with exactly: PONG-DSP produced length=8 ("PONG-DSP") — generation succeeded, the bytes just never reached the parent process.

The response lands here:

%USERPROFILE%\.gemini\antigravity-cli\
├── cache\last_conversations.json                      # { cwd -> conversation_id }
└── brain\<cid>\.system_generated\logs\
    └── transcript.jsonl                                # MODEL PLANNER_RESPONSE.content = response body

last_conversations.json keys by workspace dir, so the just-finished conversation id is recoverable from the cwd that invoked agy.

PowerShell wrapper that recovers the response

This wraps agy -p and returns the persisted response. Two non-obvious bits matter on Windows:

1. & agy.exe from PowerShell inherits stdin — without explicit closure, agy hangs forever waiting on a tty (I sat through a 20-minute stall before killing). The wrapper must close stdin.
2. cmd.exe /c with a quoted exe path + quoted prompt breaks under cmd's quote-stripping rule when the exe path contains spaces. Using System.Diagnostics.ProcessStartInfo.ArgumentList (which quotes per-argument via CommandLineToArgvW rules) avoids this.

function Invoke-AgyPrint {
    param(
        [Parameter(Mandatory)][string]$Prompt,
        [int]$TimeoutSeconds = 90,
        [string]$AgyPath = "$env:LOCALAPPDATA\agy\bin\agy.exe",
        [string]$PrintTimeout = '1m'
    )
    $cwd = (Get-Location).Path
    $psi = [System.Diagnostics.ProcessStartInfo]::new()
    $psi.FileName = $AgyPath
    $psi.ArgumentList.Add('-p')
    $psi.ArgumentList.Add($Prompt)
    $psi.ArgumentList.Add('--print-timeout'); $psi.ArgumentList.Add($PrintTimeout)
    $psi.UseShellExecute        = $false
    $psi.RedirectStandardInput  = $true
    $psi.RedirectStandardOutput = $true
    $psi.RedirectStandardError  = $true
    $psi.CreateNoWindow         = $true

    $proc = [System.Diagnostics.Process]::Start($psi)
    $proc.StandardInput.Close()   # stop agy from blocking on tty stdin

    if (-not $proc.WaitForExit($TimeoutSeconds * 1000)) {
        $proc.Kill(); throw "agy outer timeout ${TimeoutSeconds}s"
    }
    if ($proc.ExitCode -ne 0) { throw "agy exit $($proc.ExitCode)" }

    $cache = Get-Content "$env:USERPROFILE\.gemini\antigravity-cli\cache\last_conversations.json" -Raw |
             ConvertFrom-Json -AsHashtable
    $cid = $cache[$cwd]
    $tx  = "$env:USERPROFILE\.gemini\antigravity-cli\brain\$cid\.system_generated\logs\transcript.jsonl"
    $models = Get-Content $tx |
              ForEach-Object { $_ | ConvertFrom-Json } |
              Where-Object { $_.source -eq 'MODEL' -and $_.type -eq 'PLANNER_RESPONSE' }

    [pscustomobject]@{
        ConversationId = $cid
        Response       = ($models | Select-Object -Last 1).content
        Thinking       = ($models | Select-Object -Last 1).thinking
    }
}

Verified with three prompts (PONG-WRAP1, Compute 17*23. Reply with only the number., Reply only with: PONG-MODULE-OK) — all returned the exact expected response in ~10s.

Implication for the fix

Because the response is already round-tripped through the persistence layer (brain/<cid>/.system_generated/logs/transcript.jsonl), the bug is narrowly in the stdout/text_drip writeback path on Windows, not in any upstream generation or auth stage. That should narrow the surface a lot.

---

(Posted via AI translation — original drafted in Japanese.)

[MarcosNahuel]

Confirming the bug from a different invocation context — wrapping agy --print from a Claude Code plugin (Bash tool → Git Bash → agy.exe) on Windows 11. All --print invocations exit 0 with empty stdout, while text_drip.go logs the expected Drip stopped: length=N.

Complementary workaround we use today (different angle from @iwata-1116's transcript fallback): instruct agy inside the prompt to write its answer via write_file to a known absolute path, then read that file from the calling agent. Avoids stdout entirely and survives if the internal brain/<cid>/.system_generated/logs/transcript.jsonl layout ever changes. Tail we append to the user prompt:

OUTPUT INSTRUCTION: Do NOT print the answer. Write the full markdown to:
  <ABSOLUTE_PATH>
Use the write_file tool. After writing, confirm the path. That is your only deliverable.

Works for research / scrape / doc-to-md / design-review / browser-recording flows. Doesn't help trivial-prompt cases (health-check pings) — there, @iwata-1116's transcript.jsonl Plan B is the right tool.

Two data points that may help triage:

1. stdin hang is PowerShell-specific. agy.exe -p via Git Bash returns promptly with empty stdout — no tty wait. Consistent with @iwata-1116's diagnosis that the hang is PowerShell's & inheriting stdin; the upstream fix probably belongs inside agy itself (detect non-TTY stdin, don't block on it).
2. We've never observed partial stdout — it's either fully written (TTY) or fully empty (subprocess). No truncated/buffered intermediates. Suggests the flush path is conditionally skipped, not just buffered.

[geondongkim]

I can confirm this still reproduces on Windows with agy 1.0.3.

Environment:

• OS: Microsoft Windows NT 10.0.26200.0
• Shell: Windows PowerShell 5.1.26100.8457
• agy --version: 1.0.3
• Binary path: %LOCALAPPDATA%\agy\bin\agy.exe

Repro with properly quoted PowerShell Start-Process redirection:

$agy = "$env:LOCALAPPDATA\agy\bin\agy.exe"
$out = "agy.out.txt"
$err = "agy.err.txt"
$log = "agy.log"
$args = '--print "Please reply exactly: AGY_STARTPROCESS_QUOTED_20260529" --print-timeout 2m --log-file "' + $log + '"'

$sw = [System.Diagnostics.Stopwatch]::StartNew()
$p = Start-Process -FilePath $agy `
  -ArgumentList $args `
  -NoNewWindow -PassThru -Wait `
  -RedirectStandardOutput $out `
  -RedirectStandardError $err
$sw.Stop()

Get-Item $out, $err | Select-Object Name, Length
$p.ExitCode
$sw.ElapsedMilliseconds

Observed:

• exit code: 0
• elapsed: about 9,053 ms
• stdout file: 0 bytes
• stderr file: 0 bytes
• the model/backend round trip did succeed
• the expected model response was persisted in the local transcript:
  %USERPROFILE%\.gemini\antigravity-cli\brain\<conversation-id>\.system_generated\logs\transcript.jsonl

The transcript contained the final response:

{"step_index":2,"source":"MODEL","type":"PLANNER_RESPONSE","status":"DONE","created_at":"2026-05-28T15:39:48Z","content":"AGY_STARTPROCESS_QUOTED_20260529"}

So in this environment the failure mode is: agy --print completes successfully and persists the correct answer locally, but the --print stdout/stderr contract remains empty for redirected/non-interactive callers.

I also checked the transcript/log data for machine-readable usage metadata. The transcript shape is useful for a temporary importer (USER_INPUT, PLANNER_RESPONSE, RUN_COMMAND, MCP_TOOL, VIEW_FILE, tool_calls, thinking, truncated_fields), but I did not find input_tokens, output_tokens, total_tokens, usage_metadata, or similar token usage fields in the inspected CLI brain / log directories.

For automation/orchestrator use, one of these would make the CLI much easier to integrate safely:

• reliable stdout in non-TTY contexts
• --output <path>
• --format json
• --print-meta that includes conversation_id and/or transcript path
• caller-supplied or emitted conversation IDs for concurrent runs

Transcript scraping can work as a temporary workaround, but it is fragile for concurrent invocations unless agy emits a stable conversation/run identifier.