Sign up
View stargazersSign up

[Bug]: Antigravity turn ends on a dropped ACP stream: raw proxy error shown, no reconnect after a clean WebSocket close (1000)#11670

openedSep 14, 2026byMmarkusyeo

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server (Antigravity / ACP provider, session lifecycle and error handling)

Steps to reproduce

  1. T3 Code (Alpha) 0.0.40, also seen on 0.0.41-nightly.20260913.1675, on macOS. Antigravity provider, Gemini 3.8 Flash.
  2. Run a normal multi-minute turn with several tool calls.
  3. Partway through, the local Antigravity proxy (agy_acp_server at http://127.0.0.1:<port>) drops the streaming request to the model.
  4. After the turn fails, send the prompt again ("try again" or "continue").

Expected behavior

  • A dropped upstream stream (streamGenerateContent returning EOF) should be retried with backoff.
  • A clean WebSocket close (code 1000 OK) from the ACP process should reconnect, not end the turn.
  • Any error shown to the user should be readable, not a raw Go transport string.

Actual behavior

Two problems, both in T3's handling of the drop:

  1. The raw error reaches the user. When the proxy returns EOF, the adapter forwards the message unchanged and ends the turn: Agent execution error: model unreachable: doRequest: error sending request: Post "…streamGenerateContent…": EOF.
  2. A clean close is treated as fatal. On the next prompt, the session cannot recover: Failed to rebuild agent: received 1000 (OK); then sent 1000 (OK). Code 1000 is a normal close, but the rebuild path fails on it. The user has to start the turn over.

Seen in four real sessions across two builds, three on 0.0.40 (2026-09-10) and one on 0.0.41-nightly.20260913 (2026-09-14), so it survives across releases:

Session (title)Buildmodel unreachable … EOF atfatal rebuild agent: 1000 (OK) at
Add Usage Summary to Sessions0.0.402026-09-10 08:53:07Z2026-09-10 09:03:54Z
MCQ Appears Before Merge0.0.402026-09-10 12:41:33Z2026-09-10 12:44:25Z
Complete Issues and Browser Verification0.0.402026-09-10 12:41:35Z2026-09-10 12:44:16Z
Assess Vitest 5 Test Breakages0.0.41-nightly.202609132026-09-14 01:24:37Z2026-09-14 01:55:05Z

Likely code areas

References are pinned to commit c07575f573dd3a1af4f734297d17f7c951c95f10 (main), so the line numbers stay valid as the file changes. Neither error string exists in the source, so both come from the agy_acp_server binary and pass through unclassified. The handling gaps are:

Impact

A recoverable disconnect ends the turn and makes the user re-send the prompt. The message says model unreachable, so users assume the model or network is down, when it is the local proxy dropping the stream.

Version or commit

T3 Code (Alpha) 0.0.40, still reproducing on 0.0.41-nightly.20260913.1675.

Environment

  • macOS 26.5.2 (Build 25F84, arm64)
  • Antigravity provider via the local agy_acp_server proxy at http://127.0.0.1:<port>
  • Model: gemini-3.8-flash-high

Logs or stack traces

Assistant-surfaced errors, with the GCP project id and the ephemeral port masked:

1Agent execution error: model unreachable: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF
1Agent connection was lost and could not be re-established: Failed to rebuild agent: received 1000 (OK); then sent 1000 (OK)

Full provider event logs are available on request at ~/.t3/userdata/logs/provider/events.<thread>.log for the four sessions above. Scrub <project-id> before sharing.

Workaround

Send the prompt again. This usually starts a fresh agent. There is no automatic retry or reconnect.

Scrubbed per-session evidence (rendered errors + one raw provider event each)

PII masked: <project-id> (GCP project), <port> (ephemeral localhost port), /Users/<user>, <repo> (workspace repos). Only the errors T3 rendered to the user are shown, plus one raw provider event per session as proof.

Add Usage Summary to Sessions

Thread a9c32eaf, build 0.0.40.

Rendered to the user:

1[2026-09-10 08:53:07Z] Agent execution error: model unreachable: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF
2[2026-09-10 09:03:54Z] Agent connection was lost and could not be re-established: Failed to rebuild agent: received 1000 (OK); then sent 1000 (OK)

Raw provider event (first EOF), masked:

1doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF

MCQ Appears Before Merge

Thread 44be7094, build 0.0.40.

Rendered to the user:

1[2026-09-10 12:41:33Z] Agent execution error: model unreachable: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF
2[2026-09-10 12:44:25Z] Agent connection was lost and could not be re-established: Failed to rebuild agent: received 1000 (OK); then sent 1000 (OK)

Raw provider event (first EOF), masked:

1doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF

Complete Issues and Browser Verification

Thread bc8e2486, build 0.0.40.

Rendered to the user:

1[2026-09-10 12:41:35Z] Agent execution error: model unreachable: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF
2[2026-09-10 12:44:16Z] Agent connection was lost and could not be re-established: Failed to rebuild agent: received 1000 (OK); then sent 1000 (OK)

Raw provider event (first EOF), masked:

1doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF

Assess Vitest 5 Test Breakages

Thread 23e080f0, build 0.0.41-nightly.20260913.

Rendered to the user:

1[2026-09-14 01:24:37Z] Agent execution error: model unreachable: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF: doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF
2[2026-09-14 01:55:05Z] Agent connection was lost and could not be re-established: Failed to rebuild agent: received 1000 (OK); then sent 1000 (OK)

Raw provider event (first EOF), masked:

1doRequest: error sending request: Post "http://127.0.0.1:<port>/v1beta1/projects/<project-id>/locations/us/publishers/google/models/gemini-3.8-flash-high:streamGenerateContent?alt=sse": EOF
JJulius MarmingeSep 14, 2026

Triage

Confirmed as a real Antigravity / ACP reliability bug. Four sessions across 0.0.40 and 0.0.41-nightly is enough; the two user-facing strings match what the adapter forwards today.

What we verified

  1. Raw error passthrough. mapAcpToAdapterError (apps/server/src/provider/acp/AcpAdapterSupport.ts) sets detail: error.message with no transient/network branch. Antigravity only remaps sign-in. A dropped streamGenerateContent (EOF) therefore lands in chat as model unreachable: doRequest … EOF.
  2. No reconnect on the live runtime. AcpSessionRuntime.ensureConnected rethrows a latched termination. recordTermination / retireRuntime do not reconnect. AntigravityAdapter has no prompt retry/backoff. On ConnectionTerminated it tears the session down (hasSession → false).
  3. Next prompt is a full recover, then the binary fails. Recovery is ProviderService.recoverSessionForThread → startSession + resume cursor — not ProviderInstanceRegistry (that path is settings hot-reload). Neither Failed to rebuild agent nor received 1000 (OK); then sent 1000 (OK) exists in this repo. Those come from agy_acp_server (Go websocket close phrasing). T3 surfaces them unchanged. Code 1000 is a normal close; the agent’s own rebuild still fails, and we treat that as fatal.

T3 vs upstream

LayerOwns
agy_acp_server dropping streamGenerateContent with EOF, and failing its own agent rebuild on WS 1000Upstream (local Antigravity proxy). T3 cannot retry that HTTP stream.
Forwarding the raw Go string; latching the session; not retrying startSession / session/prompt after a clean closeT3

Retry-with-backoff of streamGenerateContent is the proxy’s job. T3 should still stop showing transport internals and should recover the session the way a second send often does today.

  • #10607 (open) — Grok: retire a dead ACP session so the next turn can session/load. Closest prior art. Antigravity already retires on ConnectionTerminated; the gap is classify + retry after the binary’s failed rebuild.
  • #11626 / #11628 — Antigravity cancel/queue work; not duplicates.
  • #9919 — existing pattern for classifying Antigravity init errors.

No duplicate issue found.

Proposed fix (T3)

  1. Classify EOF / model unreachable / 1000 (OK) / Failed to rebuild agent as transient in mapAntigravityError (or shared mapAcpToAdapterError). Show a short readable message.
  2. Retry startSession with backoff on that class of error. If resume/session/load hits the binary’s failed rebuild, start a fresh session instead of failing the turn.
  3. Keep in-runtime clean close as disconnect + recover, not a one-way latch.

Workaround remains: send the prompt again (often starts a fresh agent).

Accepting as bug + upstream. T3 handling should ship without waiting on the proxy.

MmarkusyeoSep 14, 2026
Synced from GitHub

Thanks for the fast triage, and for the correction on the recovery path.

You're right: recovery is recoverSessionForThread (ProviderService.ts L1227), not ProviderInstanceRegistry. That registry is the settings hot-reload path, so my fourth bullet named the wrong file. The rest lines up with what you verified: mapAcpToAdapterError forwards error.message unchanged, mapAntigravityError only remaps sign-in, and the live runtime latches on ConnectionTerminated with no retry.

I'll leave the issue body unedited so this correction stays in the thread rather than rewriting history.

Your three-part fix matches what I'd want as someone who keeps hitting this: classify the transient class, retry startSession with backoff (fresh session if resume hits the binary's failed rebuild), and treat a clean in-runtime close as a disconnect to recover from rather than a one-way latch.

I have the full provider event logs for all four sessions if the raw binary-side rebuild sequence would help. I can share them unscrubbed through a private channel; the issue only carries the masked excerpts.

MmarkusyeoSep 15, 2026
Synced from GitHub

hey @juliusmarminge any update on this and the new issue #11767

currently can't really use antigravity in t3 code until these issues are fixed