[Bug]: Antigravity + Claude permanently bricks thread after steer/resume with raw thinking.signature: Field required as completed assistant_message #28870

Activity

1. jamesdchen commented on Nov 1, 2026

   

   jamesdchen

   on Nov 1, 2026

   Author

   More actions

   Follow-up from the same session (request id req_vrtx_011CgcoGLsLVvNgybmeJxixN).

   The signature is never written, not stripped after the fact. In that Antigravity conversation the 17 planner steps have thinking text and thinking_signature length 0. Gemini sessions on the same install do store thinking_signature. The in-memory tool loop of the first turn succeeds. The next user turn replays from the database and Vertex rejects messages.1.content.0.thinking.signature.

   So this is not only steer/resume. Any second Claude turn that emitted thinking hits it. Rotating to a fresh native session (as in #28889) avoids the brick. Continuing the same native session needs the signature kept on the Gemini thought part and put back on replay. A local proxy reinjection for that is in progress and was not live-verified: the Claude & GPT 5-hour quota was exhausted before a high-thinking second turn.
2. izahai commented on Nov 5, 2026

   

   izahai

   on Nov 5, 2026

   More actions

   I reproduced this live against the managed runtime (antigravity-acp 1.4.1, claude-opus-5-5-high, AGY_ACP_FORCE_FILE_STORAGE=1) with a standalone ACP client that sends the same calls T3 sends (clientInfo: zed, oauth-personal, session/resume). The runtime does write the signature to disk. session/resume and session/load remove it.

   What breaks the session is a runtime restart, not a particular kind of turn. In my case the T3 desktop app restarted about 9 s after the first turn finished (update to 0.1.7). The next message started a new runtime and called session/resume, and every turn after that failed with messages.1.content.0.thinking.signature: Field required.

   Repro (no T3 UI involved)

   Step	ACP calls	Signature in conversations/<id>.db*	Result
   Control	session/new → prompt (thinking) → prompt, same process	present	turn 2 OK
   1	session/new → prompt (thinking) → SIGKILL the runtime	present	—
   2	new runtime → session/resume (no prompt)	gone	—
   3	prompt	gone	thinking.signature: Field required (req_vrtx_011CgiyuUD5RsvEqUXn69Myv)
   Alt	new runtime → session/load → prompt	gone	same error (req_vrtx_011CgiyqNWAfcqRv4XjaZ4CB)

   * The planner step (steps.step_type = 15) stores the thinking text at payload field 20.3 and the signature at 20.14. Gemini planner steps use 20.14 as well. After resume or load, the runtime rewrites the step with 20.3 intact and 20.14 missing, so the data is lost for good. Restarting again can't bring it back.

   Step 2 alone is enough. Resuming without sending a prompt already rewrites the step without the signature.

   Repro script (Node + Python, no dependencies): https://gist.github.com/izahai/60a69e79e03e351e18ad4befb8900f3e

   What this means for #28889

   • It reproduces every time. Any Claude session on Antigravity whose history has a thinking block breaks on its first session/resume or session/load. That covers app updates and restarts, idle reaping, steer timeouts ([Bug]: Steer on an Antigravity thread kills the turn (interruptTurn fails, then AcpProcessExitedError) #19689), and provider sign-out.
   • Rotating reactively after the error (the current PR) recovers the thread but always costs one failed turn. T3 already knows it is resuming. It could rotate before resuming instead: if the native history holds a Claude thinking step, start the fresh session with a context handoff and skip the doomed resume. The proper fix still belongs in the runtime: keep 20.14 when it loads a step.

   _{Investigated with Claude Opus 5.5.}
3. schneidervvv commented on Nov 5, 2026

   

   schneidervvv

   on Nov 5, 2026

   More actions

   Live reproduction on 0.1.8-nightly.20261104.4192 (7f6f47b27b44456f1c8214d3b566b375c09f629e) confirming both the session/resume signature stripping on delegated-subagent wakeup and the subsequent session/new -> session/load retry loop before #28889.

   Environment

   • Desktop client: 0.1.7-nightly.20261104.4151 (macOS darwin arm64, Kernel 27.0.0)
   • Server: 0.1.8-nightly.20261104.4192 (7f6f47b27b44456f1c8214d3b566b375c09f629e), Node v24.22.1
   • Provider / Model: Managed Antigravity ACP 1.4.1, claude-opus-5-5-high

   What happened & timeline

   1. Turns 1–3 (05:46:29Z–05:52:57Z): Parent thread (b8219a14-..., native session fa686dee-...) ran 3 turns on claude-opus-5-5-high (including a steering_restart on Turn 3 attempt 2 at 05:51:59Z) and delegated 3 child threads (041e4791-..., 47707934-..., c9071a90-...).
   2. Child threads vs. parent thread SQLite state:
      • All 3 child threads ran to completion inside their initial session/new runtime without ever calling session/resume or session/load. In their <session>.db files, every planner step (step_type = 15, field 20) still retains both 20.3 (thinking) and 20.14 (thinking_signature, CAQS...).
      • In the parent thread's fa686dee-...db, all 25 thinking steps have 20.3 (thinking) intact and 20.14 (thinking_signature) stripped after resume/load.
   3. Run 5 (06:28:51Z) — Subagent callback triggers cold session/resume:
      • ~36 minutes after Turn 3 completed, a delegated child thread finished and woke the parent thread.
      • T3 spawned a new ACP runtime and called initialize -> authenticate -> session/resume (06:28:54.250Z) -> session/set_config_option -> session/prompt (06:28:56.712Z).
      • Vertex AI rejected the prompt with 400 invalid_request_error: messages.1.content.0.thinking.signature: Field required (req_vrtx_011CgjJrXHzg5WdFd8vZrPfm), recorded at steps.idx = 67 (step_type = 17).
      • AntigravityTurnOutcome.ts (turnFailure, lines 95–127) read step_type = 17 and failed Run 5 (status = "failed"), flagging the adapter to restart its runtime before the next turn.
   4. Run 6 (06:31:24Z) — continue falls back to session/new + session/load on the same poisoned session:
      • On the next user prompt (continue), AcpAdapterV2 restarted the runtime (restartRuntimeAfterTeardownIfRequired), which ran initialize -> authenticate -> session/new (06:31:29.158Z), and then activateSession (packages/provider-acp/src/server/adapter.ts:7061-7084) saw canLoadSession === true and called session/load (06:31:30.248Z) on the same fa686dee-... native session.
      • session/prompt (06:31:32.138Z) failed again with messages.1.content.0.thinking.signature: Field required (req_vrtx_011CgjK3xj23rcPGVDgP4apf, steps.idx = 69, step_type = 17).

   Evidence (logs/provider/events.<thread>.log)

   [2026-11-05T06:28:54.250Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/resume","status":"started"}}
   [2026-11-05T06:28:55.551Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/resume","status":"succeeded"}}
   [2026-11-05T06:28:56.712Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/prompt","status":"started"}}
   [2026-11-05T06:28:58.339Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/prompt","status":"succeeded"}}
   [2026-11-05T06:31:25.044Z] {"kind":"request","provider":"antigravity","payload":{"method":"initialize","status":"started"}}
   [2026-11-05T06:31:29.158Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/new","status":"started"}}
   [2026-11-05T06:31:30.248Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/load","status":"started"}}
   [2026-11-05T06:31:31.196Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/load","status":"succeeded"}}
   [2026-11-05T06:31:32.138Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/prompt","status":"started"}}
   [2026-11-05T06:31:33.504Z] {"kind":"request","provider":"antigravity","payload":{"method":"session/prompt","status":"succeeded"}}
   

   ---

   Triaged with Antigravity (gemini-4-argon-medium).