fix(browser): preserve shared Chrome across concurrent sessions

[oraclexing]

Summary

Fix shared manual-login Chrome lifecycle races when several Oracle browser sessions run concurrently.

A completing controller could previously prune foreign tab leases from a single Windows process-liveness false negative, decide it owned the final lease, and terminate Chrome underneath still-running ChatGPT tabs. The observed result was one completed Deep Research run followed by chrome-disconnected partial results in its peers.

Changes

• make final-lease cleanup atomic with lease release under the registry lock
• release only the caller's lease; a controller that lost ownership cannot trigger final Chrome cleanup
• refresh active leases with a 15-second heartbeat and apply a 2-minute stale grace before reclamation
• persist process start identity so PID reuse does not strand or steal slots
• make registry writes, lock ownership/recovery, and unlock failures fail closed
• verify Windows Chrome ownership against an exact normalized --user-data-dir before termination
• preserve shared Chrome during signal cleanup while other controllers still own leases
• apply the same final-lease contract to project-sources browser runs

Verification

• pnpm run lint
• pnpm run build
• focused browser lifecycle suite: 5 files, 141 passed, 1 skipped
• full suite: 153 files passed, 18 skipped; 1,933 tests passed, 53 skipped; one 20-second load timeout in reattach.e2e.test.ts passed in 1.04s when rerun in isolation
• independent adversarial review found no remaining P0/P1 before live testing

Real signed-in Deep Research concurrency smoke (no manual Send or Answer now):

• heartbeat-gamma-two, heartbeat-alpha-two, and heartbeat-beta-two all reached promptSubmitted=true
• three distinct conversation IDs and CDP targets shared Chrome PID 18416 / port 62611
• completion order was Gamma -> Alpha -> Beta
• after Gamma and Alpha released, the remaining controller and shared Chrome stayed alive
• Chrome exited only after Beta released the final lease
• all three sessions completed and saved both a Deep Research report and transcript
• final registry was leases: [], registry lock absent, port 62611 closed, all controller/Chrome PIDs exited, and no new Windows Terminal/OpenConsole process was created

Regression coverage

Tests cover fresh liveness false negatives, lost-owner release/update, PID reuse, unavailable process identity, concurrent final release, dead/ownerless registry lock recovery, strict lock ownership, Windows retry exhaustion, exact profile-path matching, and shared-Chrome signal preservation.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 4, 2026, 1:55 PM ET / 17:55 UTC.

ClawSweeper review

What this changes

The PR coordinates concurrent manual-login browser sessions so only the final lease may terminate shared Chrome, with Windows-specific detached launch and profile-verified process cleanup.

Regression provenance

Possible regression — probable (reproduction; reviewed change). No predecessor PR is attributed.

Merge readiness

⛔ Blocked before merge - 1 item remains

Keep this active PR open for normal maintainer merge handling. The introduced lease release makes the finality decision and cleanup atomic, and the supplied Windows two-controller evidence directly exercises the concurrent shared-Chrome failure without introducing a supported correctness finding.

Priority: P2
Reviewed head: 728f03df2aab83e130f26d5c1c2f7b94a021c937

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	Detailed Windows lifecycle proof and focused race coverage support a good, mergeable reliability repair.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (terminal): The supplied exact-head Windows smoke covers the changed production lease and lifecycle boundary: the non-final controller exits, a peer continues real CDP requests against shared Chrome, and the final release observes verified shutdown.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): The supplied exact-head Windows smoke covers the changed production lease and lifecycle boundary: the non-final controller exits, a peer continues real CDP requests against shared Chrome, and the final release observes verified shutdown.
Evidence reviewed	7 items	Atomic final-lease cleanup: Release removes only the caller's lease, refuses cleanup when that record is absent, and invokes the final-release callback before the registry lock is released. Runner preserves non-final shared Chrome: The browser runner records a non-final result before cleanup and routes final termination through the verified profile terminator instead of an unguarded launcher kill. Windows ownership checks: Windows launches use detached, hidden child-process options, and final cleanup requires an exact normalized --user-data-dir match before terminating the recorded process tree.
Findings	None	None.
Security	None	None.

How this fits together

Oracle browser mode launches or reuses a Chrome profile for ChatGPT automation. A per-profile lease registry coordinates concurrent controllers and permits shared-browser cleanup only after the final controller releases its lease.

flowchart LR
A[Browser controllers] --> B[Shared Chrome profile]
B --> C[Tab lease registry]
C --> D{Final lease release?}
D -->|No| E[Keep Chrome alive]
D -->|Yes| F[Verify profile process]
F --> G[Terminate shared Chrome]
E --> H[Peer session continues]

Loading

Before merge

• Resolve merge risk (P1) - When release ownership or the recorded PID/profile cannot be verified, the intended fail-closed behavior retains Chrome and may require an operator restart of Oracle/Codex MCP to recover the slot.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production versus regression coverage	production +923/-123, tests +835/-8 across 10 files	The implementation and tests span the full shared-profile lifecycle rather than a single local guard.

Merge-risk options

Maintainer options:

1. Keep fail-closed cleanup (recommended)
   Accept retained Chrome as the recovery behavior when registry release or process ownership cannot be safely verified.
2. Pause for lifecycle-policy revision
   Hold the PR if maintainers want a different operator-recovery contract for registry locks or unmatched Chrome PIDs.

Technical review

Best possible solution:

Merge the atomic release and profile-verified Windows lifecycle path while retaining conservative shared-Chrome preservation when cleanup safety cannot be proven.

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

Yes. The supplied exact-head Windows two-controller smoke has a concrete path: exit a non-final controller, verify the peer continues CDP operations, then verify termination after the peer's final release.

Is this the best way to solve the issue?

Yes. Atomic caller-only lease release plus exact profile-specific termination is the narrowest maintainable fix for the concurrent shared-Chrome lifecycle race.

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P2: This is a bounded concurrent browser-session reliability repair.
• merge-risk: 🚨 availability: An incorrect final-lease or Windows process decision could terminate active shared Chrome or retain it unnecessarily.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The supplied exact-head Windows smoke covers the changed production lease and lifecycle boundary: the non-final controller exits, a peer continues real CDP requests against shared Chrome, and the final release observes verified shutdown.
• proof: sufficient: Contributor real behavior proof is sufficient. The supplied exact-head Windows smoke covers the changed production lease and lifecycle boundary: the non-final controller exits, a peer continues real CDP requests against shared Chrome, and the final release observes verified shutdown.

Evidence

What I checked:

• Atomic final-lease cleanup: Release removes only the caller's lease, refuses cleanup when that record is absent, and invokes the final-release callback before the registry lock is released. (src/browser/tabLeaseRegistry.ts:215, 728f03df2aab)
• Runner preserves non-final shared Chrome: The browser runner records a non-final result before cleanup and routes final termination through the verified profile terminator instead of an unguarded launcher kill. (src/browser/index.ts:960, 728f03df2aab)
• Windows ownership checks: Windows launches use detached, hidden child-process options, and final cleanup requires an exact normalized --user-data-dir match before terminating the recorded process tree. (src/browser/profileState.ts:130, 728f03df2aab)
• Focused regression coverage: The focused tests cover concurrent final release, foreign-lease preservation, heartbeat draining, stale/lost records, PID reuse, lock recovery, and Windows profile matching. (tests/browser/tabLeaseRegistry.test.ts:388, 728f03df2aab)
• Real Windows lifecycle proof: The PR body and exact-head correction report a two-controller Windows smoke where the departing non-final owner left the peer able to complete twenty CDP checks, followed by verified final Chrome termination. (728f03df2aab)
• Current main does not contain this lifecycle repair: From the PR base to fetched current main, the only browser change is effort-label matching; the introduced shared-Chrome lifecycle paths remain unique to this open branch. (src/browser/actions/thinkingTime.ts, be6c92a9e4cc)

Likely related people:

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

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (4 earlier review cycles)

• reviewed 2026-09-02T19:52:19.827Z sha ad76711 :: needs changes before merge. :: [P1] Make the Windows path expectations portable
• reviewed 2026-09-02T21:01:49.242Z sha 728f03d :: blocked before merge. :: none
• reviewed 2026-09-03T01:21:56.242Z sha 728f03d :: blocked before merge. :: none
• reviewed 2026-09-03T15:35:24.275Z sha 728f03d :: blocked before merge. :: none

[oraclexing]

@clawsweeper re-review

Author correction for head 728f03df:

The PR body's initial causal attribution is superseded. Multi-process registry stress did not reproduce lease loss. The higher-confidence Windows root cause was controller process ownership: chrome-launcher started the shared Chrome as a normal child of the controller that launched it, so controller exit could close Chrome underneath still-valid peer leases.

The new commit adds native-Windows detached: true + windowsHide: true, preserves non-Windows/WSL behavior, drains in-flight lease heartbeats before release, adds exact final/non-final telemetry, and makes both launched and reused manual-login final cleanup use the verified PID/profile terminator (hidden tree kill + post-kill liveness polling). It also fixes the POSIX compatibility finding by making Windows path/case assertions Windows-scoped.

Exact-head verification:

• lint/typecheck, build, and diff-check passed
• focused browser suite: 5 files, 140 passed, 1 skipped
• heartbeat/release overlap test passed 10 consecutive runs
• full suite with 8 workers: 156 files passed / 18 skipped; 1,977 tests passed / 53 skipped
• independent lifecycle review: GO, no P0/P1

Real Windows two-controller smoke:

• owner launched Chrome PID 48300 / port 57689; peer acquired another lease and target
• owner release was non-final with peer still recorded, then owner controller exited
• after owner exit, peer completed 20 consecutive /json/version, /json/list, and target-scoped Runtime.evaluate checks
• peer release was final; verified termination succeeded; registry empty and endpoint unreachable

Final-kill smoke separately verified PID 14808 / port 64198 alive+reachable before cleanup and both absent after; no new WindowsTerminal/OpenConsole process appeared.

Evidence boundary: a later Deep Research session was manually submitted by the user, so its final promptSubmitted=true must not be treated as automatic-send proof. Exact-head headless ChatGPT attempts were blocked by Cloudflare; this head claims exact process/lease/CDP lifecycle proof, not a new signed-in automatic-submit proof.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/33703537575
• Updated: 2026-09-03T01:25:30.789Z