fix(browser): persist managed Chrome cookies across restarts by TurboTheTurtle · Pull Request #98284 · openclaw/openclaw

TurboTheTurtle · 2026-06-30T22:24:50Z

Summary

Preserve managed openclaw browser cookies across restarts by letting Chrome close gracefully through browser-level CDP Browser.close before falling back to signals.
For new local macOS headless managed profiles, launch Chrome with --use-mock-keychain and mark the profile so future launches keep the same cookie encryption backend.
Leave existing managed profiles on their existing keychain backend; the PR does not switch an established profile to mock keychain.
Add focused browser lifecycle/profile tests.

What Problem This Solves

Managed browser sessions can hold login cookies in Chrome's live CDP cookie store while the profile's SQLite cookie DB remains empty. When OpenClaw stops and relaunches the managed browser without a graceful Chrome close, those cookies can disappear, so users lose authenticated browser state even when reusing the same managed profile.

Issue #96704 has a live repro against current upstream origin/main showing a CDP-visible persistent cookie before restart, 0 rows in Chrome's cookie DB, and 0 cookies after relaunch with the same profile.

Security / Product Shape

This final version does not store cookies in an OpenClaw plaintext sidecar. Cookie material stays in Chrome's profile storage.

For new local macOS headless managed profiles, the PR opts the isolated OpenClaw-owned profile into Chromium's mock keychain so headless Chrome can persist encrypted cookies without login-keychain prompts. That marker is stored in the managed profile's Local State.

For existing managed profiles created before this PR, the PR does not change the cookie encryption backend. The recovery path is: existing profiles keep their current backend and gain graceful Browser.close shutdown; sessions already lost by previous ungraceful restarts cannot be reconstructed and require signing in again.

Evidence

Before-fix live repro against upstream main: [Bug]: Managed browser cookies never persist to disk (in-memory only) — login sessions lost on every browser/gateway restart (reproduces on 2026.6.10; refile of #15645) #96704 (comment)
Exact-head proof was captured on 96e8fa6c6629d9f0d7950fd295de0bf894dbecf6 using isolated temp gateway/browser ports 19984/19995, synthetic cookies only, temp state dirs under /private/tmp, and channel startup disabled.
Branch refresh 4377e6203386a3536e4125e8449543ef2d45d4ec rebased onto current origin/main, removed the release-owned CHANGELOG.md edit, and kept the browser files identical to the proven head (git diff --name-status 96e8fa6c6629..4377e620338 -- browser files is empty).

Fresh profile proof:

Built PR head locally with pnpm build.
Started a fresh managed profile on PR head with --headless; process args included --use-mock-keychain.
Profile marker after launch: profile.info_cache.Default.openclaw_mock_keychain=true.
Set synthetic persistent cookie oc98284_smoke through browser-level CDP Storage.setCookies; Storage.getCookies returned matchingCookies=1.
Stopped browser through openclaw browser stop; Chrome Cookies DB contained example.test|oc98284_smoke|valueLen=0|encryptedLen=51|isPersistent=1.
Relaunched same profile on PR head; Storage.getCookies returned totalCookies=1, matchingCookies=1, value present.

Upgraded current-main profile proof:

Built current origin/main at 45f561ab6c2.
Created the managed profile on current main with --headless; process args did not include --use-mock-keychain.
Current-main-created profile marker before upgrade: openclaw_mock_keychain=false.
Switched the same temp home/state dir to PR head 96e8fa6c6629.
Started the existing profile on PR head; process args still did not include --use-mock-keychain, and the marker remained false.
Set synthetic persistent cookie oc98284_after_upgrade through browser-level CDP; Storage.getCookies returned matchingCookies=1.
Stopped browser through PR-head openclaw browser stop; Chrome Cookies DB contained after-upgrade.example.test|oc98284_after_upgrade|valueLen=0|encryptedLen=67|isPersistent=1.
Relaunched the same upgraded profile on PR head; Storage.getCookies returned totalCookies=1, matchingCookies=1, value present.

Validation on refreshed PR head 4377e6203386a3536e4125e8449543ef2d45d4ec:

node scripts/run-vitest.mjs extensions/browser/src/browser/chrome.internal.test.ts extensions/browser/src/browser/chrome.test.ts: 107/107 passed.
node_modules/.bin/oxfmt --check extensions/browser/src/browser/chrome.ts extensions/browser/src/browser/chrome.test.ts extensions/browser/src/browser/chrome.internal.test.ts extensions/browser/src/browser/chrome.profile-decoration.ts
node_modules/.bin/oxlint extensions/browser/src/browser/chrome.ts extensions/browser/src/browser/chrome.test.ts extensions/browser/src/browser/chrome.internal.test.ts extensions/browser/src/browser/chrome.profile-decoration.ts
git diff --cached --check && git diff --check

Fixes #96704

clawsweeper · 2026-06-30T22:25:59Z

Codex review: needs maintainer review before merge. Reviewed July 5, 2026, 8:29 PM ET / 00:29 UTC.

Summary
The PR changes the browser plugin to request CDP Browser.close before signal fallback, opt new macOS headless managed profiles into mock keychain with a Local State marker, and add focused lifecycle/profile tests.

PR surface: Source +80, Tests +106. Total +186 across 4 files.

Reproducibility: yes. The linked issue includes a current-main live repro for a synthetic persistent cookie disappearing after managed browser restart, and current main source lacks the PR's Browser.close and mock-keychain persistence path.

Review metrics: 1 noteworthy metric.

Managed Chrome persistence surfaces: 1 launch flag added, 1 profile marker added. The PR changes the Chrome startup/security surface for new macOS headless managed profiles and records that choice in Chrome Local State.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #96704
Summary: This PR is the current candidate fix for the canonical managed-browser cookie/session-loss issue; the earlier issue and stale PR are historical context, not better canonical landing targets.

Members:

canonical: [Bug]: Managed browser cookies never persist to disk (in-memory only) — login sessions lost on every browser/gateway restart (reproduces on 2026.6.10; refile of #15645) #96704 - The PR body uses closing syntax for this open current-main repro issue, and the issue is the fresh canonical report for managed Chrome cookie loss across restarts.
superseded: [Feature]: Persist browser cookies/sessions across managed browser restarts (CDP cookie flush) #15645 - It reported the same cookie/session-loss symptom but was stale-closed with a request for a fresh latest-release repro, which the canonical issue now provides.
partial_overlap: feat(browser): persist login sessions across restarts #45371 - It attempted the same symptom with a sidecar cookie snapshot design but was closed unmerged as stale and security/product-wrong for current main.

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P2] Maintainer should explicitly accept or reject the mock-keychain security tradeoff before merge.

Risk before merge

[P1] New macOS headless managed profiles will store Chrome cookies under Chromium's mock keychain path instead of the normal login keychain; that is the intentional tradeoff that makes headless persistence work but should be accepted as a security-boundary decision.
[P1] The patch changes managed browser session shutdown semantics, so maintainers should treat cookie/session persistence and process ownership as merge-critical even though focused tests and current checks are positive.

Maintainer options:

Accept The Managed-Profile Tradeoff (recommended)
Maintainers can merge after checks finish, explicitly accepting mock keychain for new macOS headless managed profiles and keeping existing profiles on their current backend.
Require A Non-Mock Keychain Path
Ask for a revised design that persists cookies without switching new macOS headless profiles to Chromium's mock keychain.
Pause Until Broader Browser Persistence Is Decided
Hold or close this PR if maintainers want cookie/session persistence solved as part of a wider browser-state design rather than a Chrome shutdown/keychain fix.

Next step before merge

[P2] No automated code repair is indicated; the next action is maintainer/security acceptance of the session-state and mock-keychain merge risk, with normal exact-head checks gating merge.

Maintainer decision needed

Question: Should new local macOS headless managed profiles use Chromium's mock keychain, with existing profiles pinned to their current backend, as the accepted fix for managed Chrome cookie persistence?
Rationale: The code appears correct and avoids plaintext cookie duplication, but it deliberately changes how sensitive browser cookies are protected for new macOS headless profiles, which is a product/security ownership choice rather than a pure test result.
Likely owner: steipete — He owns the relevant browser runtime history and already added the current PR's process-ownership guard.
Options:
- Accept Bounded Mock-Keychain Fix (recommended): Merge after current-head required checks are green, accepting the isolated managed-profile mock-keychain behavior as the security/session-state tradeoff.
- Require Different Keychain Design: Pause the PR and require a design that preserves normal macOS keychain behavior for new headless profiles, accepting that unattended persistence may remain broken until then.
- Defer Cookie Persistence: Close or hold this PR and keep the linked issue open until maintainers choose a broader browser-session persistence strategy.

Security
Needs attention: Needs attention: the patch avoids plaintext cookie duplication, but intentionally uses Chromium's mock keychain for new macOS headless managed profiles.

Review details

Best possible solution:

Land this bounded Chrome-owned persistence fix after maintainer acceptance of the mock-keychain security tradeoff, keeping cookie material inside Chrome's managed profile rather than adding an OpenClaw cookie sidecar.

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

Yes. The linked issue includes a current-main live repro for a synthetic persistent cookie disappearing after managed browser restart, and current main source lacks the PR's Browser.close and mock-keychain persistence path.

Is this the best way to solve the issue?

Yes, with a maintainer security decision. The PR follows the prior recommended shape by improving Chrome shutdown/profile handling and avoiding an OpenClaw plaintext cookie sidecar; the remaining choice is accepting mock keychain for new macOS headless profiles.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

add merge-risk: 🚨 session-state: Merging changes how managed Chrome sessions preserve cookies across restarts, so a bug could lose, stale, or mis-associate browser login state.
add merge-risk: 🚨 security-boundary: The fix affects protection of browser cookies by selecting Chromium's mock keychain for new macOS headless managed profiles.
add proof: sufficient: Contributor real behavior proof is sufficient. The PR body contains terminal-style live proof for fresh and upgraded managed profiles with synthetic cookies, and the current-head Real behavior proof check passed; no new contributor proof is needed from this review.
add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body contains terminal-style live proof for fresh and upgraded managed profiles with synthetic cookies, and the current-head Real behavior proof check passed; no new contributor proof is needed from this review.

Label justifications:

P1: The PR targets a user-facing managed browser session-loss bug that can break SSO-backed browser automation across browser or gateway restarts.
merge-risk: 🚨 session-state: Merging changes how managed Chrome sessions preserve cookies across restarts, so a bug could lose, stale, or mis-associate browser login state.
merge-risk: 🚨 security-boundary: The fix affects protection of browser cookies by selecting Chromium's mock keychain for new macOS headless managed profiles.
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 PR body contains terminal-style live proof for fresh and upgraded managed profiles with synthetic cookies, and the current-head Real behavior proof check passed; no new contributor proof is needed from this review.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body contains terminal-style live proof for fresh and upgraded managed profiles with synthetic cookies, and the current-head Real behavior proof check passed; no new contributor proof is needed from this review.

Evidence reviewed

PR surface:

Source +80, Tests +106. Total +186 across 4 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	103	23	+80
Tests	2	133	27	+106
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	4	236	50	+186

Security concerns:

[medium] Accept mock-keychain cookie protection tradeoff — extensions/browser/src/browser/chrome.ts:757
New macOS headless managed profiles gain persistent cookies by using Chromium's mock keychain, so maintainers should explicitly accept that sensitive browser session state is protected by the isolated managed profile rather than the normal login keychain.
Confidence: 0.82

What I checked:

Repository policy read: Read the root and scoped extension policies; bundled plugin boundary and compatibility/security-sensitive review rules apply to this browser plugin change. (AGENTS.md:1, 2c31af136429)
Current main stop path: Current main stops managed Chrome by signaling the child process and polling CDP reachability; it does not request a browser-level graceful close before SIGTERM/SIGKILL. (extensions/browser/src/browser/chrome.ts:1132, 2c31af136429)
PR graceful close path: The PR adds requestGracefulChromeClose, sends Browser.close, waits for CDP shutdown, and falls back to SIGTERM/SIGKILL only when the graceful close path does not shut Chrome down. (extensions/browser/src/browser/chrome.ts:1151, 9a83733eee6c)
PR process-ownership guard: The maintainer follow-up commit avoids sending Browser.close to a reused fixed CDP port after the tracked child has already exited or been signaled. (extensions/browser/src/browser/chrome.ts:1207, 9a83733eee6c)
PR keychain backend gating: The PR only enables --use-mock-keychain on macOS when a profile already carries OpenClaw's marker or when a new managed profile is being launched headless, preserving established profiles' existing backend. (extensions/browser/src/browser/chrome.ts:947, 9a83733eee6c)
Profile marker implementation: The PR stores and reads openclaw_mock_keychain under Chrome's profile info cache so later launches keep the same encryption backend instead of silently switching. (extensions/browser/src/browser/chrome.profile-decoration.ts:117, 9a83733eee6c)

Likely related people:

steipete: Peter Steinberger introduced the original browser control path, moved browser ownership to the bundled plugin, maintained CDP startup behavior, closed the prior sidecar-based implementation with product/security direction, and added the current PR's process-ownership guard. (role: browser runtime owner and recent PR contributor; confidence: high; commits: 208ba02a4a65, 8eeb7f082975, 58da2f5897fe; files: extensions/browser/src/browser/chrome.ts, extensions/browser/src/browser/server-context.availability.ts, extensions/browser/src/browser/chrome.profile-decoration.ts)
John-Rood: Authored the earlier closed PR that attempted managed-browser login persistence for the same symptom, which remains useful context even though that branch was rejected for storage/security shape. (role: prior implementation author; confidence: medium; commits: 6d46c867d685, 040aa5f64a87; files: src/browser/session-persistence.ts, src/browser/chrome.ts, src/browser/server-context.availability.ts)
Agustin Rivera: Recent history on the same browser plugin includes CDP hostname/navigation hardening, which is adjacent to this PR's browser-level CDP control path and security review surface. (role: adjacent CDP/security contributor; confidence: medium; commits: 121c452d66, 80720b4994; files: extensions/browser/src/browser/chrome.ts, extensions/browser/src/browser/cdp.helpers.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

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.

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.

Review history (8 earlier review cycles)

reviewed 2026-07-01T06:33:49.715Z sha 1e9c646 :: needs maintainer review before merge. :: none
reviewed 2026-07-05T20:48:34.903Z sha eec53c2 :: needs real behavior proof before merge. :: [P1] Restore a real cookie persistence path before closing the bug
reviewed 2026-07-05T20:55:36.145Z sha eec53c2 :: needs real behavior proof before merge. :: [P1] Restore a real cookie persistence path before closing the bug
reviewed 2026-07-05T21:38:24.443Z sha 96e8fa6 :: needs real behavior proof before merge. :: [P1] Cover upgraded profiles before closing the cookie-loss bug
reviewed 2026-07-05T22:06:23.604Z sha 96e8fa6 :: needs maintainer review before merge. :: none
reviewed 2026-07-05T22:21:36.173Z sha 4377e62 :: needs maintainer review before merge. :: none
reviewed 2026-07-05T22:28:30.549Z sha 4377e62 :: needs maintainer review before merge. :: none
reviewed 2026-07-05T22:35:07.871Z sha 4377e62 :: needs maintainer review before merge. :: none

TurboTheTurtle · 2026-07-01T01:19:55Z

Updated the PR with the proof ClawSweeper asked for.

Changes since the review:

Successful empty Storage.getCookies now deletes cookies.json, so logout/clear-cookie state is not restored later.
The cookie flush interval now has idempotent cleanup on managed Chrome exit/close and normal stop.

After-fix live proof on 4588b338bc3, using an isolated temp gateway/browser:

Set oc98284_after_fix via browser-level CDP: matchingCookies=1.
Stopped browser: sidecar written as mode=600, cookieCount=1, hasProof=true.
Relaunched same profile: Storage.getCookies returned matchingCookies=1.
Cleared cookies via CDP, stopped browser: sidecar absent.
Relaunched again: Storage.getCookies returned totalCookies=0, matchingCookies=0.

Validation:

Focused browser Vitest: 57/57
oxfmt --check
oxlint
git diff --check origin/main...HEAD

@clawsweeper re-review

clawsweeper · 2026-07-01T01:19:58Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

TurboTheTurtle · 2026-07-01T04:27:12Z

Addressed the two ClawSweeper findings in ee5511b692f.

Changes:

reset-profile now deletes the managed Chrome cookies.json sidecar before moving the profile dir, so reset cannot restore old login cookies into the fresh profile.
Restore now normalizes saved Storage.getCookies snapshots into Storage.setCookies params and omits expires for session cookies where CDP returns expires: -1.
Added focused coverage for both reset sidecar cleanup and session-cookie normalization.

Validation:

Focused browser Vitest: 61/61
oxfmt --check
oxlint
git diff --check origin/main...HEAD

@clawsweeper re-review

clawsweeper · 2026-07-01T04:27:14Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

steipete · 2026-07-06T00:31:40Z

Maintainer verification complete on the security-preserving redesign.

What changed from the original cookie-sidecar proposal:

cookies remain exclusively in Chromium's profile store; no plaintext cookies.json, periodic export, restore hook, or duplicated credential state;
managed Chrome receives browser-level CDP Browser.close before bounded SIGTERM / SIGKILL fallback so Chromium can flush profile state without making Gateway shutdown unbounded;
only a brand-new macOS headless OpenClaw-managed profile opts into Chromium's non-interactive mock keychain;
a durable marker keeps that new profile on the same key source, while every established profile retains its previous key source so an upgrade cannot make existing cookies unreadable.

Security decision:

I accept the deterministic mock-keychain tradeoff for this narrow profile class. The profile is new, isolated, OpenClaw-owned, and same-user private (0700 in the live proof); Browser/CDP access already grants that OS user equivalent session authority. The patch does not migrate existing profiles, copy cookies into OpenClaw state/config/logs, expose a new endpoint, or widen the Browser trust boundary. A plaintext sidecar would be a materially worse credential boundary and is intentionally not included.

Automated proof:

final head 9a83733eee6ce27e455fb2761a45d852f5d5c8e4 passed every selected exact-head Linux Node 24 gate in CI run 28759963733: build, QA smoke, lint, production/test types, dependency and architecture boundaries, plugin/channel contracts, and all Node test shards;
exact-head focused Chrome suites passed 109/109, including the process-ownership regressions added after review; oxfmt and git diff --check also passed;
fresh final-head Codex autoreview found no accepted/actionable findings, correctness confidence 0.86;
the exact head built successfully on macOS before live proof;
direct Chrome 150 upgrade proof on the same Browser patch showed a profile created by current main kept its original key source: no mock-keychain flag or marker was added, and its persistent synthetic cookie survived graceful close/relaunch.

Real Gateway/OpenAI/Browser proof on exact head:

started an isolated Dev Gateway at 9a83733 with OpenAI gpt-5.5, a fresh HOME/state/profile created specifically for this final head, and Browser as the agent's only tool;
a fresh agent navigated to example.com, set an explicit persistent cookie (Max-Age=86400), read it in a separate Browser call, and returned FINAL_COOKIE_SET_OK;
sent SIGUSR1 to the Gateway. The Gateway restarted in-process with the same PID 88846, the old Chrome PID 94120 exited, and Chromium flushed one matching row to its encrypted cookie DB;
before relaunch, no Chrome listener remained. A new agent session then started Chrome PID 1865, navigated without setting or modifying cookies, read the durable cookie, and returned FINAL_COOKIE_SURVIVED_RESTART_OK;
after relaunch the profile marker remained true, the matching DB row remained present, and no cookies.json existed anywhere under the isolated OpenClaw state directory.

Scope note: a session cookie without Expires / Max-Age correctly did not survive a full Chrome process restart; that is Chromium session-cookie behavior, not the persistent-cookie loss reported in #96704. This patch fixes the issue's explicit persistent-cookie/SSO repro without exporting session cookies into a weaker sidecar.

The shared sanitized-AWS pool was at its active-lease cap when this final head was ready, so I did not reuse another task's lease. The approved secretless exact-head hosted fork CI path above provided the full automated gate; macOS-specific keychain and Gateway behavior was proven live on the exact commit. Known proof gaps: none.

steipete · 2026-07-06T00:32:16Z

Merged via squash.

Prepared head SHA: 9a83733eee6ce27e455fb2761a45d852f5d5c8e4
Landed commit: d9289a19e160a50686ba7e1bd181fb2ca45e1213

…w#98284) * fix(browser): preserve managed Chrome cookies * fix(browser): guard graceful close process ownership --------- Co-authored-by: Peter Steinberger <[email protected]>

openclaw-barnacle Bot added docs Improvements or additions to documentation size: M triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jun 30, 2026

openclaw-barnacle Bot removed the triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. label Jun 30, 2026

TurboTheTurtle marked this pull request as ready for review July 1, 2026 04:26

TurboTheTurtle force-pushed the codex/96704-browser-cookie-persistence branch from ee5511b to 1e9c646 Compare July 1, 2026 06:16

openclaw-barnacle Bot added gateway Gateway runtime size: L and removed size: M labels Jul 1, 2026

clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. labels Jul 1, 2026

openclaw-barnacle Bot added size: S and removed docs Improvements or additions to documentation gateway Gateway runtime size: L labels Jul 5, 2026

clawsweeper Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jul 5, 2026

steipete force-pushed the codex/96704-browser-cookie-persistence branch from 4377e62 to 1670486 Compare July 5, 2026 23:57

TurboTheTurtle and others added 2 commits July 5, 2026 20:17

fix(browser): preserve managed Chrome cookies

68542cb

fix(browser): guard graceful close process ownership

9a83733

steipete force-pushed the codex/96704-browser-cookie-persistence branch from 1670486 to 9a83733 Compare July 6, 2026 00:17

steipete merged commit d9289a1 into openclaw:main Jul 6, 2026
141 of 156 checks passed

steipete mentioned this pull request Jul 6, 2026

docs(changelog): note browser cookie persistence #100507

Merged

github-actions Bot mentioned this pull request Jul 6, 2026

📡 Upstream Digest — 2026-07-06 02:26 UTC curtismercier/openclaw-mods#1220

Open

clawsweeper Bot mentioned this pull request Jul 6, 2026

fix(gateway): format usage dates in range timezone #100567

Merged

TurboTheTurtle deleted the codex/96704-browser-cookie-persistence branch July 6, 2026 06:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(browser): persist managed Chrome cookies across restarts#98284

fix(browser): persist managed Chrome cookies across restarts#98284
steipete merged 2 commits into
openclaw:mainfrom
TurboTheTurtle:codex/96704-browser-cookie-persistence

TurboTheTurtle commented Jun 30, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 30, 2026 •

edited

Loading

Uh oh!

TurboTheTurtle commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading

Uh oh!

TurboTheTurtle commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

TurboTheTurtle commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What Problem This Solves

Security / Product Shape

Evidence

Uh oh!

clawsweeper Bot commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TurboTheTurtle commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TurboTheTurtle commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

TurboTheTurtle commented Jun 30, 2026 •

edited

Loading

clawsweeper Bot commented Jun 30, 2026 •

edited

Loading

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading