Browser mode loses completed Pro answer after recoverable CDP disconnect (0.16.0)

[hoyanhan]

Summary

With @steipete/oracle 0.16.0 in browser mode, a long Pro run submitted successfully and ChatGPT later completed a full answer, but Oracle lost its target-level CDP client shortly before completion and reported:

ERROR: Chrome window closed before oracle finished. Please keep it open until completion.
Chrome disconnected before completion; keeping session running for reattach.

Chrome did not close. The persistent browser process remained running, its loopback CDP endpoint remained reachable, and the same page target was still present in /json/list. ChatGPT completed the response server-side around two minutes later, and the full answer was recoverable manually, but Oracle never captured it.

Environment

• Oracle: unmodified npm @steipete/oracle 0.16.0
• Node.js: 24.14.1
• OS: Ubuntu 24.04, x86_64
• Chrome: 150
• Engine: browser
• Model: gpt-5-pro
• Manual-login persistent browser profile with Chrome already running over loopback CDP
• Browser response timeout: 20 minutes
• CLI timeout: 60 minutes
• Heartbeat: 30 seconds
• Approximately 17.6k input tokens, with seven text files inlined using --browser-attachments never

Command shape:

oracle --engine browser \
  --model gpt-5-pro \
  --browser-attachments never \
  --timeout 60m \
  --heartbeat 30 \
  --browser-archive never \
  -p "<structured prompt>" \
  --file "<file>" ...

Timeline

1. At T+0, Oracle verified the Pro picker and recorded promptSubmitted=true.
2. Every 30 seconds through T+16m, Oracle logged that no thinking status was detected.
3. At approximately T+16m43s, the target-level CDP client disconnected and Oracle reported that the Chrome window had closed.
4. The browser service had not restarted, CDP remained reachable, the same target still existed, and there was no kernel OOM or Chrome crash evidence.
5. ChatGPT completed the full response at approximately T+18m.
6. Oracle left the session and model run in running state with incompleteReason=chrome-disconnected.
7. The stored runtime had only the root https://chatgpt.com/ URL and no conversation ID.
8. A later oracle session <id> --harvest captured a generic ChatGPT error banner rather than the completed answer. Follow-up recovery also failed because the session contained no ChatGPT conversation URL.
9. No transcript or response artifact was written.

The initiating cause of the CDP WebSocket disconnect is not yet proven. The confirmed problem is that Oracle classified a recoverable client disconnect as a closed Chrome window and could not reconnect to the still-live target.

Source-level behavior

In src/browser/index.ts, any client disconnect is mapped to:

Chrome window closed before oracle finished

In src/cli/sessionRunner.ts, the connection-loss path keeps the session marked as running and prints reattach guidance, but it did not automatically reconnect in this run.

Recovery was then ineffective because no /c/... conversation URL had been persisted. Keeping the session in running state is insufficient when the target is still available but Oracle cannot resolve the completed conversation.

Expected behavior

When the CDP client disconnects:

1. Distinguish a client/WebSocket disconnect from an actually closed browser or target by probing the CDP endpoint and recorded target.
2. If the target remains alive, reconnect to it and continue waiting or harvest the completed response.
3. Apply the existing auto-reattach concept to the connection-lost path, not only assistant timeouts.
4. Persist the conversation URL/ID as early as possible after submission.
5. If the URL is unavailable, retain a recovery fallback based on the recorded target ID and prompt preview.
6. Reconcile a recovered completed response to status=completed rather than leaving the session permanently running.
7. Preserve the underlying disconnect reason instead of replacing every client disconnect with “Chrome window closed.”

Related issues

• Browser mode: thinking-state detection can miss (ChatGPT UI drift) — live runs look dead; reattach then binds a stale tab target #284 reported missed thinking-state detection and stale-target recovery. It was closed as fixed by fix(browser): recover remote Chrome sessions reliably #289 and fix(browser): require completion proof for short captures #293, but this 0.16.0 run still lost a completed response after a CDP disconnect while the browser and target remained alive.
• Browser mode tears down Chrome on long Pro runs, losing the still-running ChatGPT conversation #138 covered long Pro runs losing a still-running conversation. Its fix preserved the session for reattach, but this case shows that preservation alone is not sufficient when no recoverable conversation URL is stored.

I have retained the detailed local logs privately. The prompt, response, project names, paths, account details, session IDs, conversation IDs, hostnames, and process IDs have intentionally been omitted.

[clawsweeper]

🦞🔧
ClawSweeper is automatically building this issue.

The issue review finished and no active implementation pull request was found.

Automatic implementation progress:

• State: Queued
• Detail: Review complete; no active implementation PR was found. The Codex implementation worker is queued.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29427331106
• Updated: 2026-07-15T15:17:40.357Z
• Opt out: add clawsweeper:manual-only or clawsweeper:human-review.

[piyushbag]

Working claim + repro plan

I am taking a focused fix for this. ClawSweeper has a queued auto-implement; this PR will stay narrow and differentiated: recoverable CDP-client disconnect handling + connection-lost auto-reattach (the path that already exists for assistant-timeout but not for connection-lost).

Source-level repro (no live ChatGPT required)

1. In src/browser/index.ts, any client disconnect sets connectionClosedUnexpectedly and rejects with "Chrome window closed..." without probing /json/version or /json/list.
2. The catch path rewrites socket/client disconnects to stage: "connection-lost" with that same message.
3. In src/cli/sessionRunner.ts, connection-lost keeps the session running and prints reattach guidance, but only assistant-timeout calls autoReattachUntilComplete.
4. Existing unit coverage in tests/cli/sessionRunner.test.ts asserts the "keep running" behavior and does not assert an automatic resume.

Fix shape

1. On CDP client disconnect, probe the debug endpoint (and recorded target when present). If Chrome/target is still alive, surface recoverableDisconnect instead of "Chrome window closed."
2. On connection-lost with a recoverable runtime (promptSubmitted and/or conversation URL/target), attempt a single auto-reattach resume (reuse resumeBrowserSession), then mark completed on success.
3. Keep the current "session stays running + guidance" fallback when resume fails.
4. Add regression tests for the probe + connection-lost auto-reattach path.

Will open a PR shortly with Fixes #326.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 16, 2026, 2:11 PM ET / 18:11 UTC.

Summary
Keep open: current main still treats a target-level CDP disconnect as a closed Chrome window and does not invoke automatic reattach from the resulting connection-lost path. The specifically linked implementation at #327 should remain the active resolution path until it merges or is otherwise resolved.

Likely related people: @LeoLin990405 for the recent conversation recovery implementation, Peter Steinberger for extensive recent browser-path maintenance, and Felix Huber for the original auto-reattach work.

Reproducibility: yes. at source level: current main maps the client disconnect to connection-lost, keeps the session running, and returns before the existing auto-reattach routine. The initiating network event was not reproduced live, but the failing state transition is clear from source and the reporter supplied a detailed observed timeline.

Root-cause cluster
Relationship: canonical
Canonical: #326
Summary: This issue is the canonical report for the connection-lost recovery gap; the linked open PR is its candidate fix, while the older reports cover adjacent timeout, stale-target, and premature-capture paths.

Members:

• fixed_by_candidate: fix(browser): recover answers after recoverable CDP disconnect #327 - The open PR explicitly implements recoverable CDP liveness probing and connection-lost auto-reattach for this report.
• partial_overlap: Browser mode: thinking-state detection can miss (ChatGPT UI drift) — live runs look dead; reattach then binds a stale tab target #284 - That closed issue involved stale-target and missing-conversation-URL recovery, but not this still-live target-level CDP disconnect branch.
• partial_overlap: Browser mode tears down Chrome on long Pro runs, losing the still-running ChatGPT conversation #138 - That closed issue established preserving long Pro sessions after interruption, while this report shows preservation without reconnection can still lose the completed answer.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
Keep the issue open while the specifically linked fix PR is reviewed; a competing ClawSweeper repair PR should not be queued.

Review details

Best possible solution:

Review and land the linked PR after a forced target-client disconnect smoke proves that Oracle reconnects to the same submitted conversation, captures the completed answer, marks the session completed, and safely retains the existing running-session fallback when recovery cannot be established.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: current main maps the client disconnect to connection-lost, keeps the session running, and returns before the existing auto-reattach routine. The initiating network event was not reproduced live, but the failing state transition is clear from source and the reporter supplied a detailed observed timeline.

Is this the best way to solve the issue?

Yes in direction: extending the established resume path after a positive endpoint-and-target liveness probe is narrower and safer than creating a second recovery system. The implementation still needs real forced-disconnect proof covering successful recovery and the safe fallback.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The initiating CDP WebSocket disconnect cause remains unproven, so recovery must avoid retry loops, reconnecting to the wrong target, or resubmitting a prompt when endpoint or target identity is ambiguous.
• The linked PR currently reports only focused tests and typechecking; a forced-disconnect browser smoke is still needed to prove that a completed Pro answer is harvested from a genuinely live target.

Codex review notes: model internal, reasoning high; reviewed against 8e3456e7f2dc.

Label changes

Label changes:

• add P1: A real long-running browser workflow can complete successfully in ChatGPT while Oracle loses the answer and leaves the session permanently running.
• add impact:message-loss: The completed assistant answer is not captured into a transcript or response artifact after the recoverable disconnect.
• add impact:session-state: The saved Oracle session remains running with incomplete recovery metadata after ChatGPT has completed the response.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P1: A real long-running browser workflow can complete successfully in ChatGPT while Oracle loses the answer and leaves the session permanently running.
• impact:message-loss: The completed assistant answer is not captured into a transcript or response artifact after the recoverable disconnect.
• impact:session-state: The saved Oracle session remains running with incomplete recovery metadata after ChatGPT has completed the response.

Evidence reviewed

What I checked:

• Current-main disconnect classification: The browser run installs a CDP client disconnect handler that marks the connection unexpectedly closed and rejects with the closed-window error without first proving that Chrome or the target disappeared. citeturn679972view0. (src/browser/index.ts, 8e3456e7f2dc)
• Current-main recovery gap: The connection-lost branch preserves the session as running and returns after printing reattach guidance; autoReattachUntilComplete is invoked only from the separate assistant-timeout branch. citeturn359560view0. (src/cli/sessionRunner.ts:3242, 8e3456e7f2dc)
• Documented recovery contract: The README describes automatic browser reattach for long Pro runs and says incomplete runs remain available for manual reattach, supporting the reported expectation that a still-live conversation should remain recoverable. citeturn818044view0. (README.md:310, 8e3456e7f2dc)
• Linked implementation candidate: The open fix(browser): recover answers after recoverable CDP disconnect #327 explicitly targets this issue with CDP liveness probing and connection-lost auto-reattach, so the issue must remain open until that candidate merges or is closed. (c4a7755cc101)
• Adjacent recovery provenance: Merged fix(browser): recover remote Chrome sessions reliably #289 added conversation URL persistence and saved-conversation reattach behavior for a related stale-target failure, but it did not change this disconnect classification and recovery branch. (src/browser/index.ts, d3a7df0f137b)

Likely related people:

• LeoLin990405: Authored the merged remote-session recovery work that persists conversation URLs and prefers saved conversations during reattach, directly adjacent to this failure mode. (role: recent recovery feature contributor; confidence: high; commits: d3a7df0f137b; files: src/browser/conversationUrlMonitor.ts, src/browser/reattach.ts, src/browser/index.ts)
• Peter Steinberger: Recent repository history shows repeated browser-mode reliability changes and integration work across the central browser and session-runner paths. citeturn818044view0. (role: recent browser area contributor and merger; confidence: high; commits: 75ed9bf, 77c0b19, 3f083fa; files: src/browser/index.ts, src/cli/sessionRunner.ts)
• Felix Huber: Repository release history credits Felix Huber with the browser auto-reattach mechanism that the proposed connection-loss fix would reuse. citeturn818044view0. (role: auto-reattach feature introducer; confidence: medium; files: src/cli/sessionRunner.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.