Stalled browser runs report 'response streaming' indefinitely, and dead runs stay 'running' in oracle status forever

[postoso]

Version: oracle 0.17.3, browser engine, GPT-5.6 Sol at Pro thinking time, 60 minute auto-timeout

Two related gaps, both visible in one run.

1. The progress line computes a stall signal and discards it

Verbatim tail of ~/.oracle/sessions/<slug>/output.log for a run that died:

[browser] ChatGPT thinking - 1m 0s elapsed; status=response streaming; last change 30s ago; source=inline
[browser] ChatGPT thinking - 5m 59s elapsed; status=response streaming; last change 5m 29s ago; source=inline
[browser] ChatGPT thinking - 8m 29s elapsed; status=response streaming; last change 7m 59s ago; source=inline
<log ends here — no completion, no timeout, no error>

The page stopped changing at the 30 second mark. Every subsequent line's "last change" tracks exactly 30 seconds behind "elapsed", which means zero DOM change after 0:30. Oracle went on reporting status=response streaming for another eight minutes.

The information needed to detect the stall is already computed and printed on the same line that reports health. Nothing consumes it. A threshold on "last change" (say, no change for N minutes while claiming to stream) would turn eight minutes of false confidence into an actionable state.

I realize thinking-state detection has been touched before (#284, closed). This is not about misreading the UI: the reading is correct and the log is accurate. The gap is that the derived value is never acted on.

2. A dead run's session record is never reaped

That same run's process stopped writing at the timestamp above. Sixty-eight minutes after launch, well past the documented 60 minute auto-timeout, oracle status still listed it as:

running   GPT-5.6 Sol   br/fg   <timestamp>   2698   -  <slug>

There is no reaper for the session status record. It reports running indefinitely.

Why 2 has a cost beyond tidiness

oracle status is the documented way to check whether the profile is busy before launching, since concurrent launches against one profile can interfere. An orphaned running row is indistinguishable from a live run from the outside, so the correct and the safe behavior diverge: a well-behaved caller waits on a corpse. This happened here — a second session held its launch for over an hour on a run that had been dead the whole time, and resolving it required inspecting session metadata by hand.

Worth noting the asymmetry: the browser tab lease does self-heal, since tabLeaseRegistry prunes on PID liveness. It is only the status record that persists. So the resource is actually free while the thing callers are told to consult still says it is taken.

Suggested direction

For 2, the PID-liveness check the lease registry already performs would settle it: a record whose process is gone, or which has exceeded the auto-timeout with no writes, could be marked stale or died rather than left as running. Distinguishing "died" from "completed" would also make 1 easier to surface.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 21, 2026, 5:20 PM ET / 21:20 UTC.

Summary
Keep open for a maintainer decision: current code deliberately keeps a browser session running when Chrome remains reachable after its Oracle worker/controller exits, which conflicts with using status as a reliable busy indicator.

Reproducibility: yes. —current source and tests construct a dead controller with reachable Chrome and retain running; the reporter also supplied a SIGTERM path, though this review did not execute it.

Root-cause cluster
Relationship: canonical
Canonical: #391
Summary: This issue is the canonical remaining lifecycle-status question; the earlier browser thinking-detection report is adjacent but distinct.

Members:

• adjacent_distinct: Browser mode: thinking-state detection can miss (ChatGPT UI drift) — live runs look dead; reattach then binds a stale tab target #284 - It concerned UI thinking detection and stale tab targeting; the reporter explicitly withdrew that part here and narrowed this issue to lifecycle reconciliation.

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

Maintainer decision needed

Question	Recommendation
Should a browser session whose Oracle worker/controller has exited but whose ChatGPT tab remains reachable be shown as running, or as a recoverable terminal state?	Use a recoverable terminal state: Mark the Oracle session error or incomplete when its worker exits, retain Chrome metadata and allow oracle session to reattach.

Why: Current docs and tests prioritize reattaching after CLI interruption, while the report’s valid SIGTERM case needs oracle status to distinguish a live Oracle worker from a recoverable orphan.

Next step
A maintainer must choose the public meaning of running before a small lifecycle repair can safely change it.

Review details

Best possible solution:

Define running as an Oracle worker that is still alive, then record controller-dead sessions as recoverable/terminal with the existing reattach metadata so status no longer advertises a false busy slot.

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

Yes—current source and tests construct a dead controller with reachable Chrome and retain running; the reporter also supplied a SIGTERM path, though this review did not execute it.

Is this the best way to solve the issue?

Unclear until the lifecycle contract is chosen; a recoverable terminal state is the narrowest path that preserves reattach without presenting a dead Oracle worker as busy.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Marking every controller-dead session as terminal could discard the current reattach path for a still-active ChatGPT tab; retaining the current behavior leaves callers unable to distinguish that recoverable state from an Oracle worker that is actually live.

Codex review notes: model internal, reasoning high; reviewed against 083bba7e61f4.

Label changes

Label justifications:

• P1: A dead Oracle worker can keep the documented session-status coordination path blocked for real browser users.
• impact:session-state: The issue concerns persisted session lifecycle metadata reporting a non-terminal run as running.

Evidence reviewed

What I checked:

• Current reconciliation preserves the reported state: Session listing reconciles metadata, but a running browser session remains running when any Chrome PID or DevTools port is reachable; the dead Oracle worker is not by itself terminal. (src/sessionManager.ts:802, 6b17e6db0cae)
• Existing regression coverage codifies reachable Chrome as running: The current test explicitly expects a running browser session to remain running after an old start time when the Chrome runtime is reachable, matching the remaining report rather than resolving it. (tests/sessionManager.test.ts:339, 6b17e6db0cae)
• Recovery behavior is intentional: Docs and the reattach test describe preserving a browser session after foreground CLI interruption so a reachable ChatGPT tab can later be recovered. (docs/sessions.md:75, 6b17e6db0cae)
• Current-release provenance: Blame attributes the reconciliation and stale-session logic to the v0.17.3 release commit; that tag contains the commit, so the conflicting behavior is present in the reported release rather than only current main. (src/sessionManager.ts:807, 6b17e6db0cae)
• Reporter narrowed the claim: The reporter withdrew the DOM-stall heuristic and supplied a focused SIGTERM scenario for the unreaped session record, leaving lifecycle reconciliation as the actionable concern.

Likely related people:

• Peter Steinberger: Current reconciliation, its tests, and the associated session documentation blame to the v0.17.3 release commit authored by Peter Steinberger. (role: recent session-lifecycle contributor; confidence: high; commits: 6b17e6db0cae; files: src/sessionManager.ts, tests/sessionManager.test.ts, docs/sessions.md)

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.

[postoso]

Correcting part of my own report. The first half of this issue is wrong and I withdraw it. The second half stands and is strengthened.

Withdrawing the "stall signal is computed and discarded" claim

I argued that because the progress line prints last change 7m 59s ago while reporting status=response streaming, oracle holds a stall signal it never acts on.

That inference does not hold. I ran a fresh Pro run today and watched a healthy one produce the identical pattern:

[browser] ChatGPT thinking - 30s elapsed; status=response streaming; source=inline
[browser] ChatGPT thinking - 3m 0s elapsed; status=response streaming; last change 2m 30s ago
[browser] ChatGPT thinking - 6m 0s elapsed; status=response streaming; last change 5m 30s ago

The DOM legitimately does not change for minutes while Pro is reasoning, so a growing last change is expected behavior rather than evidence of a stall. It does not discriminate a thinking run from a dead one, which is exactly the property my suggested threshold would have needed. Acting on it would produce false positives on ordinary long runs. Oracle is right not to.

Apologies for the noise on that half.

What actually happened in the original run, restated

Stripped of the bad inference, the observation is narrower and still real: a run went silent with no completion, no timeout, and no error line — the log simply ends — and its session record then stayed running indefinitely.

Note the contrast with today's run, which ended properly:

[browser] Released ChatGPT browser slot 553d7125.
ERROR: Assistant response timed out before completion; reattach later to capture the answer.

That is the correct shape: the slot is released and the failure is announced. The original run produced neither. So the open question is not "why didn't oracle detect a stall" but "why did that run terminate without emitting either a completion or a timeout," and the answer to that is not something I can see from outside.

The unreaped running record stands, with more evidence

I have now observed three of these in a single day, all the same shape: process gone, session record still running, no reaper because reconciliation is read-triggered rather than a background sweep.

1. The original run in this report.
2. A run I killed myself with SIGTERM while it was mid-flight. Record still running well after the process was gone.
3. A run belonging to a separate session that exited deliberately and went dark; its record sat at running for over half an hour with no process behind it.

Case 2 is trivially reproducible: launch a browser run, SIGTERM the client, then check oracle status. The row stays running.

The cost remains what I described: oracle status is the documented way to check whether the profile is busy before launching, and an orphaned row is indistinguishable from a live run from outside, so a well-behaved caller waits on something already dead. That happened twice today across sessions.

If it is easier to triage, I am happy for this issue to be re-scoped to the unreaped record alone and the terminated-without-signal question split out, since only the first is cleanly actionable.