Browser: completed ChatGPT response is never captured when thinking indicator is absent

[kesslerio]

Summary

On current ChatGPT browser UI, Oracle can successfully submit a small text-only prompt and ChatGPT can complete the answer, while Oracle continues reporting that no thinking status was detected and never captures the completed assistant turn.

This appears to be a regression or remaining gap after #284 / #293. It is distinct from #327: no DevTools disconnect occurred in this reproduction.

Reproduction

1. Run Oracle in browser mode through oracle serve against an already signed-in, persistent manual-login Chrome profile.
2. Use the current active model (gpt-5.5-pro here) and submit a short synthetic exact-token prompt; no attachments are needed.
3. Wait for the browser response timeout.

Actual behavior

Oracle repeatedly logged:

Waiting for ChatGPT response - <elapsed>; no thinking status detected yet.

The bounded foreground client timed out without a captured answer. It did not report a CDP disconnect.

Direct CDP inspection of the still-live ChatGPT conversation showed:

• a /c/<id> conversation URL;
• the synthetic exact token appeared twice in document.body.innerText (the submitted user turn and the completed assistant reply); and
• no visible data-testid="stop-button" control.

So ChatGPT had completed the response, but Oracle did not recognize or harvest it.

Expected behavior

Once Oracle has submission evidence and a conversation URL, lack of a recognized thinking indicator should not by itself prevent response capture. Oracle should fall back to polling the current conversation for a newly added assistant turn and require robust terminal evidence before completing it.

The existing safeguards from #293 still matter: a fallback should use a post-submit turn baseline, associate the assistant turn with the current conversation, and require stable content plus no active streaming control before accepting a result.

Environment

• Oracle published 0.16.0, then current main at f13347973b (the unreleased 0.16.1 changelog changes were installed for confirmation)
• Linux x86_64, Google Chrome 144.0.7559.109
• Browser engine, remote oracle serve, persistent manual-login profile
• Current-model strategy; active model reported as gpt-5.5-pro

Related

• Browser mode: thinking-state detection can miss (ChatGPT UI drift) — live runs look dead; reattach then binds a stale tab target #284 identified missing thinking-state detection and stale-tab recovery; it was closed by later fixes, but this short current-UI reproduction still misses a completed assistant turn.
• fix(browser): require completion proof for short captures #293 added stricter completion proof, which a fallback should preserve rather than bypass.
• fix(browser): recover answers after recoverable CDP disconnect #327 is installed in the reproduction and is not exercised here because Chrome and the target stayed connected.

I can test a focused patch against the same Linux remote-service setup.

[dbachko]

I reproduced this on current main with GPT-5.6 Sol and traced the missed terminal answer to conversation scoping rather than the absence of a thinking indicator itself.

Immediately after submission, ChatGPT briefly exposed a transient URL like:

https://chatgpt.com/c/WEB:32229414-5afa-4478-890c-9ca80aa82430

Oracle's loose /c/<id> matcher persisted WEB as the expected conversation ID. ChatGPT then replaced the route with the durable /c/<uuid> URL, but the completed assistant snapshot was rejected because its UUID did not match the persisted WEB scope. The UI showed a terminal answer with no stop control while Oracle continued logging no thinking status detected yet.

#334 makes transient routes ineligible for persistence and uses one stable extractor in response capture, reattachment, and live-tab harvesting. The patch passed the full suite and live GPT-5.6 Sol, explicit Pro, Pro Deep Research, and reattach smokes without clicking Answer now.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this issue: Browser: completed ChatGPT response is never captured when thinking indicator is absent This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[steipete]

Fixed by #334, merged as 19a0b79.

Root cause: after submission, ChatGPT can briefly expose /c/WEB:<request-id> before replacing it with the durable /c/<uuid> route. Oracle's loose matcher persisted WEB as the expected conversation scope. When the completed assistant turn arrived on the UUID route, the existing scope guard correctly rejected it as a different conversation; the resulting timeout misleadingly reported that no thinking status was detected.

The fix centralizes durable conversation-ID extraction, rejects colon-delimited transient routes, waits to persist the durable URL, and applies the same parsed-path rule to live-tab and reattachment recovery. The recovery gate also rejects query and fragment lookalikes.

Proof on the landed head: 1,591 tests passed (43 skipped), pnpm check and pnpm build passed, and all hosted checks are green: Ubuntu, macOS, Windows, Linux CDP disconnect proof, and GitGuardian. The reporter also confirmed the fixed server and remote-client routes against the original signed-in Linux reproduction.