Browser mode: recovered/error runs can release the lease while retaining Oracle-owned tabs indefinitely

[lhysin]

Summary

In browser mode with a persistent manual-login profile, an Oracle-owned ChatGPT tab can survive an error after its browser lease is released. If the tab is intentionally kept for recovery, a later successful session --harvest / reattach still appears to close only the CDP attachment, not retire the original Oracle-owned page target.

This means retained error/recovery tabs can accumulate independently of maxConcurrentTabs: the active lease count stays bounded, but old Oracle-owned targets can remain in the shared Chrome while later runs acquire freed leases and open new targets.

I am not suggesting that all failed/rate-limited tabs should be closed immediately. I have local cases where a run first failed on a visible ChatGPT rate-limit warning and a later harvest recovered useful output. The gap is the lack of a bounded retirement path after recovery is no longer needed or after recovery succeeds.

Environment

Oracle CLI: 0.18.0
Engine: browser
Profile: persistent manual-login profile
maxConcurrentTabs: 3
Platform: macOS

I also checked current main at bbc1b3b0261d (2026-08-28); the lifecycle described below is still present there.

What I observed

During repeated browser work across multiple independent work units, the shared Oracle Chrome accumulated dozens of old ChatGPT tabs while the configured active lease limit remained bounded.

The persistent Chrome profile also retained session state containing roughly 48-49 distinct ChatGPT conversation URLs in its recent Default/Sessions/Tabs_* files. I do not claim every retained conversation came from this exact path, but it is consistent with the visible tab accumulation.

For the rate-limit trigger specifically, I found eight local Oracle sessions that correctly recorded the ChatGPT modal as:

code: chatgpt-ui-warning
uiWarning.type: rate_limit
message: Too many requests ... You're making requests too quickly ...

At least three of those sessions were later harvested successfully (harvest.state=completed), which is why immediate close-on-error would be unsafe.

Source-level lifecycle

Current src/browser/index.ts has:

function shouldCloseOwnedRunTargetAfterRun(options: {
  runStatus: "attempted" | "complete";
  ownsTarget: boolean;
  keepBrowser: boolean;
  closeOwnedTabOnComplete?: boolean;
}): boolean {
  return (
    options.runStatus === "complete" &&
    options.ownsTarget &&
    (Boolean(options.closeOwnedTabOnComplete) || !options.keepBrowser)
  );
}

The browser lease is still released from the run's finally path. So an errored/incomplete run can release its lease without closing its owned target.

With another active lease keeping the shared Chrome alive, this sequence is possible:

run A opens/owns target A
-> run A errors after submission
-> runStatus remains "attempted"
-> shouldCloseOwnedRunTargetAfterRun(...) == false
-> lease A is released
-> another lease keeps shared Chrome alive
-> target A remains open for possible recovery
-> a later run acquires the freed lease and opens target A2

Repeating this grows retained page targets without violating maxConcurrentTabs.

The recovery path also seems to lack a retirement step. In current src/browser/reattach.ts, successful reattach/harvest calls closeAttached(), which closes the CDP connection to the target, then returns the recovered answer. It does not appear to close the original Oracle-owned target after recovery succeeds.

So the lifecycle can become:

error/incomplete
-> keep target for recovery          # desirable
-> release lease
-> later harvest/reattach succeeds
-> session can become completed
-> original target still remains     # no explicit retirement path found

Rate-limit is a trigger, not the core bug

PR #395 correctly improved ChatGPT rate-limit detection. I am not reporting that rate limits are undetected.

Rate limiting just makes this lifecycle easy to exercise: it produces terminal-for-now browser errors, and retries after the lease is freed can create additional targets. The underlying issue is target lifetime versus lease/session lifetime.

There is also an adjacent classification edge in the generic UI-warning path: a warning discovered while constructing createAssistantTimeoutError() is emitted with stage="assistant-timeout", while browser preservation is stage-based. That can make a UI warning follow the same preservation lifecycle as a genuine incomplete assistant capture. This is secondary to the missing post-recovery retirement path above.

Expected behavior

I think recovery retention and tab cleanup need to be separated explicitly. Possible directions:

1. Keep Oracle-owned targets for genuinely recoverable errors, but retire them after a successful harvest/reattach once the recovered output is persisted.
2. Close owned targets immediately for errors known to be terminal/non-recoverable.
3. Add a bounded retention/TTL or reconciliation cleanup for recoverable targets that are never harvested.
4. Track target ownership/recoverability explicitly enough that cleanup does not risk closing a still-useful long-running response.

A regression test could hold one shared-profile lease open, make another owned run enter an error/recoverable state and release its lease, then verify that:

• the target is retained while recovery is still needed, and
• the target is retired after successful recovery (or another explicit terminal reconciliation event).

Related work

• Browser mode tears down Chrome on long Pro runs, losing the still-running ChatGPT conversation #138: preserve long-running ChatGPT conversations instead of tearing Chrome down too early.
• Browser mode: thinking-state detection can miss (ChatGPT UI drift) — live runs look dead; reattach then binds a stale tab target #284: stale target / thinking-state recovery.
• Browser mode loses completed Pro answer after recoverable CDP disconnect (0.16.0) #326: recover completed answers after recoverable CDP disconnects.
• Stalled browser runs report 'response streaming' indefinitely, and dead runs stay 'running' in oracle status forever #391 / PR fix(browser): reap dead session records when controllerPid is gone #413: reconcile dead session records that remain running.
• PR fix(browser): close completed serve-owned tabs #328: close completed serve-owned tabs while keeping the shared browser alive.
• PR fix(browser): report ChatGPT's rate limit as a rate limit #395: correctly report ChatGPT's Too many requests modal as a rate limit.

Those changes explain why retaining a target can be necessary. This report is about the opposite edge of the lifecycle: a retained target can outlive its useful recovery window while its lease is already reusable.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 1, 2026, 6:06 PM ET / 22:06 UTC.

Summary
Keep open: current main preserves incomplete Oracle-created tabs after releasing their lease, while successful harvest/reattach paths persist output or detach CDP without retiring that tab. The cleanup boundary needs maintainer direction before a safe repair can be scoped.

Reproducibility: yes. —source inspection provides a high-confidence path: retain an attempted Oracle-owned target in a shared manual-login Chrome, then complete recovery through harvest or reattach and observe that no target-close operation follows.

Root-cause cluster
Relationship: canonical
Canonical: #435
Summary: This is a distinct retained-target lifecycle gap; prior browser recovery and completed-run cleanup work is adjacent but does not own post-recovery retirement.

Members:

• partial_overlap: fix(browser): close completed serve-owned tabs #328 - It added cleanup for completed serve-owned tabs but intentionally preserves incomplete/reattachable targets.
• partial_overlap: Browser mode loses completed Pro answer after recoverable CDP disconnect (0.16.0) #326 - It concerns recovering a completed answer after a CDP disconnect, not retiring a target once recovery succeeds.

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

Maintainer decision needed

Question	Recommendation
Should a successfully recovered Oracle-owned tab be closed immediately after durable output persistence, or retained under an explicit bounded reconciliation policy?	Close after successful recovery: Persist original ownership and close only the recorded Oracle-created target after the recovered answer and artifacts are durable.

Why: Current code deliberately retains incomplete targets for recovery but does not persist a complete ownership/retention decision that a later harvest can safely enforce.

Next step
A maintainer must first choose the safe ownership and retention policy; an automated repair should not guess which retained targets may be closed.

Review details

Best possible solution:

Persist enough original-target ownership and recoverability state to retire only an Oracle-created target after recovered output is committed, while preserving attached and still-recoverable tabs.

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

Yes—source inspection provides a high-confidence path: retain an attempted Oracle-owned target in a shared manual-login Chrome, then complete recovery through harvest or reattach and observe that no target-close operation follows.

Is this the best way to solve the issue?

Unclear—the lifecycle gap is established, but immediate cleanup versus bounded reconciliation requires a maintainer-owned policy that protects recoverable work and user-owned tabs.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Closing a recovered target unconditionally could discard a still-useful long-running response or a user-attached tab unless original Oracle ownership and recovery completion are distinguishable at cleanup time.

Codex review notes: model internal, reasoning high; reviewed against 40c188caa861.

Label changes

Label justifications:

• P2: Retained browser tabs can accumulate during repeated recoverable runs, but the report does not establish a crash, data loss, or security boundary failure.
• impact:other: The issue concerns shared-browser resource retention and tab growth, which is a concrete operator-visible impact outside the more specific taxonomy.

Evidence reviewed

What I checked:

• Completed-only cleanup condition: The run-target cleanup predicate returns true only for a complete run that owns its target; an attempted/incomplete run is deliberately retained. (src/browser/index.ts:914, 40c188caa861)
• Lease release does not change incomplete cleanup: The finalizer releases the tab lease and calls the target-close callback, but that callback is disabled when the run remains attempted; this permits the lease to become reusable while the target remains open. (src/browser/index.ts:2447, 40c188caa861)
• Harvest has no target-retirement step: A successful harvest persists metadata and returns the captured output; its finally block only handles a newly launched recovery Chrome process, not the original recorded target. (src/cli/browserTabs.ts:307, 40c188caa861)
• Reattach closes its CDP attachment: The reattach helper stores a connection-close callback and invokes it after capture; the connection is created with target disposal disabled, so this is not a target-retirement path. (src/browser/reattach.ts:79, 40c188caa861)
• Current regression coverage encodes retention: The browser cleanup tests explicitly expect an attempted owned target not to close, but provide no corresponding post-recovery retirement assertion. (tests/browser/index.test.ts:143, 40c188caa861)
• Feature-history provenance: Merged PR fix(browser): close completed serve-owned tabs #328 introduced the completed-run tab cleanup policy; current history after the report contains no browser lifecycle change addressing recovered-target retirement. (653c621b7ff7)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• rtl-ai: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.