What Problem This Solves

• Fixes an issue where users could hit Chrome launch failures or stuck startup while OpenClaw retained the entire Chrome launch stderr stream in memory before diagnostics were rendered.
• Affected surface / workflow: Managed Chrome startup in extensions/browser/src/browser/chrome.ts, specifically the launch path that waits for CDP readiness and includes stderr diagnostics when startup fails.
• Root cause, in product terms: The original PR correctly moved stderr retention toward a bounded 64 KiB launch buffer, but the retained tail became the only source for stale Singleton-lock recovery, missing-display/profile-lock hints, and final rendered diagnostics. Early recovery markers could roll out of the tail, the displayed 2,000 characters came from the start of the retained tail instead of the newest failure output, and byte trimming could start inside a UTF-8 character.
• Why it matters / User impact: Chrome startup failures should keep OpenClaw memory bounded without regressing existing retry/hint behavior or showing stale/malformed diagnostics. Users still need the latest redacted Chrome failure output plus existing recovery guidance.

Why This Change Was Made

• Fix classification: Root cause fix.
• Complete shipped solution: The launch path now stores stderr through a bounded diagnostics accumulator: it keeps the 64 KiB byte tail for redacted display, tracks recovery/hint signals while chunks stream, renders the newest display slice with slice(-CHROME_STDERR_HINT_MAX_CHARS), and drops leading continuation bytes before UTF-8 decoding so diagnostics do not start with replacement characters after a boundary trim.
• Why this is root-cause fix: The memory bound remains at the stderr collection boundary, while the downstream behavior that previously depended on the full stderr stream now has independent bounded state for the facts it needs. This fixes the correctness regressions instead of widening the retained buffer or adding an after-the-fact fallback.
• Source of truth boundary: launchOpenClawChrome remains the owner of managed-Chrome launch diagnostics and retry decisions. The source of truth for the public diagnostic size cap remains CHROME_STDERR_HINT_MAX_CHARS; this patch only changes the private launch-time stderr retention and signal tracking that feed that existing diagnostic path.
• Scope boundary / what did not change: No dependency, workflow, public API, config, schema, launch-timeout, retry-count, Chrome launch argument, CDP readiness probing, browser selection, redaction policy, displayed diagnostic cap, or post-success Chrome stderr behavior changes. The listener is still detached and the retained diagnostics state is cleared when the launch attempt exits.
• Compatibility, merge-risk, or maintainer-decision notes: No public API, user config, schema, protocol, wire/data format, default value, or migration contract changes. This is an internal managed-Chrome launch diagnostic behavior fix. A real managed-Chrome failure proof has now been supplied for the current head, using a locally installed Chrome executable and the actual launchOpenClawChrome implementation.
• Risk labels considered: merge-risk: availability.
• Risk explanation: Browser startup failure handling is availability-sensitive: a regression could disable stale-lock recovery, hide missing-display/profile-lock hints, or show stale/malformed stderr during Chrome launch failures.
• Why acceptable: The patch narrows that availability risk by preserving recovery/hint facts independently from the bounded display tail, rendering the newest stderr slice, and adding focused regressions for the exact retry/hint/display/UTF-8 cases requested by the maintainer. It does not change launch arguments, CDP probing, retry count, timeouts, public configuration, or post-success Chrome behavior.
• Related open PR scan / contract boundary: init-pr detected no linked issues for this PR, and this repair does not define or extend a public contract. No competing contract PR is needed to own the private stderr-retention behavior; the source of truth remains launchOpenClawChrome.
• Out of scope boundary: Public browser configuration semantics, Chrome executable discovery, CDP diagnostic protocol behavior, and redaction policy are out of scope for this code repair. The real binary proof below covers the managed-Chrome launch-failure diagnostic path; OS-specific stale Singleton lock and missing-DISPLAY setup remain covered by the deterministic focused regressions.

User Impact

• Users/operators/developers can now: Hit noisy Chrome launch failures with bounded stderr memory while still getting the newest redacted stderr tail and the existing stale-lock / missing-display guidance when those markers appeared earlier in the stream.
• Existing behavior preserved: Stale Chromium Singleton lock recovery still runs from the original marker, missing-display/profile-lock hints still render, stderr is still redacted before display, and the displayed hint remains capped by CHROME_STDERR_HINT_MAX_CHARS.
• What was not tested or remains unavailable: Real binary proof is complete for the managed-Chrome launch-failure reporting path on Windows using Chromium's --crash-test startup flag through the actual Chrome binary. Additional live OS/session setups for Linux missing-DISPLAY and active stale Singleton lock are not part of this local proof run; the marker-specific behavior for those cases is covered by focused regressions because the code change is the bounded stderr retention/signaling layer, not platform setup or Chrome lock creation.

Evidence

• Environment: Windows Git Bash task worktree; Node v22.17.0; pnpm v11.2.2. After syncing current origin/main, local proof and validation were rerun against PR head 7fe9bfcf83588d142380ce1e14ef9c827414310c. The real Chrome proof used an explicit local live-proof opt-in with a prepared Windows environment and a direct managed-Chrome launch attempt.

• Main sync: daily_fix.sh check-main-drift reported sync_main_required=true; daily_fix.sh sync-main replayed the two PR commits onto current origin/main, then the validations below were rerun.

• Remote checks after sync: Current PR head 7fe9bfcf83588d142380ce1e14ef9c827414310c settled with FAIL 0 / PENDING 0 / PASS 69 / SKIPPED 30 after the sync push.

• Commands run after this patch:

  • CI=1 NO_COLOR=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-browser.config.ts extensions/browser/src/browser/chrome.internal.test.ts --reporter=verbose — exit 0.
  • pnpm exec oxfmt --check --threads=1 extensions/browser/src/browser/chrome.ts extensions/browser/src/browser/chrome.internal.test.ts — exit 0; output included All matched files use the correct format.
  • pnpm exec oxlint extensions/browser/src/browser/chrome.ts extensions/browser/src/browser/chrome.internal.test.ts --deny-warnings — exit 0.
  • git diff --check — exit 0.
  • A one-off proof harness ran with OPENCLAW_HOME, OPENCLAW_CONFIG_PATH, and OPENCLAW_REAL_CHROME_EXE set for an isolated local Chrome proof environment — exit 0. The harness imported launchOpenClawChrome from the current PR head, used a locally installed real Chrome executable (not mocked child_process.spawn), launched managed Chrome with --crash-test, and waited for CDP on an OpenClaw-managed loopback port.

• Real managed-Chrome launch-failure proof:

  • Result: expected managed Chrome launch failure.

  • Observed Failed to start Chrome CDP: yes.

  • Observed redacted Chrome stderr: section: yes.

  • Sanitized excerpt:

    Failed to start Chrome CDP on port 53652 for profile "daily-fix-proof-14652". CDP diagnostic: http_unreachable after 11ms; cdp=http://127.0.0.1:53652; fetch failed: connect ECONNREFUSED 127.0.0.1:53652.
    Chrome stderr:
    :549] Component extension Chrome PDF Viewer (mhjfbmdgcfjbbpaeojofohoefgiehjai) installing/upgrading from '' to 1
    [8088:15584:0708/114050.176:VERBOSE1:extensions\browser\extension_registrar.cc:547] AddComponentExtension Google Hangouts
    [8088:15584:0708/114050.176:VERBOSE1:extensions\browser\extension_registrar.cc:549] Component extension Google Hangouts (nkeimhogjdpnpccoofpliimaahmaaome) installing/upgrading from '' to 1.3.26
    [8088:15584:0708/114050.185:VERBOSE1:chrome\browser\profiles\profile_manager.cc:2065] ForceSigninCheck: 0, 0, 1
    DevTools listening on ws://127.0.0.1:53652/devtools/browser/822007d2-dd8e-4053-9637-8a7a57c9e7dc
    [0708/114050.201:ERROR:third_party\crashpad\crashpad\client\crashpad_client_win.cc:142] crash server failed to launch, self-terminating
    

• Key results / observations: The focused browser Vitest file now covers the maintainer-requested cases: early Singleton marker plus more than 64 KiB of later stderr still triggers stale-lock retry; final/newest stderr marker is displayed; split multibyte trimming does not introduce �; early missing-display marker plus later tail rollover still produces the display hint. The real Chrome proof confirms the current head still reports managed-Chrome launch failure through the actual launchOpenClawChrome path with a redacted stderr section.

• Review findings addressed, if any:

  • RF-001 / RF-007 maintainer changes requested — fixed in code and covered by the focused browser Vitest regressions listed above.
  • RF-002 / RF-003 / RF-004 / RF-006 real behavior proof requests — supplied via the real managed-Chrome launch-failure proof above for current head 7fe9bfcf83588d142380ce1e14ef9c827414310c.
  • RF-005 availability-sensitive path — risk is called out above; focused regressions cover stale-lock recovery, missing-display hint preservation, newest stderr rendering, and UTF-8-safe trimming.

• Regression guardrail: extensions/browser/src/browser/chrome.internal.test.ts now exercises early Singleton recovery after tail rollover, missing-display hint preservation after tail rollover, newest output rendering, and UTF-8 split-boundary trimming.

• Patch quality notes: Production diff remains limited to extensions/browser/src/browser/chrome.ts; tests remain in the existing browser internal test file. The added fs.existsSync return true / return false branches are test-only fixture path controls, and the added catch blocks only capture the expected launch error message for assertions. No local debug files, lockfiles, generated artifacts, or dependency changes are included.

• Maintainer-ready confidence: High: the maintainer-requested code repair is covered by focused current-head regressions, and the current head now includes a real managed-Chrome launch-failure proof instead of relying on mocked Vitest coverage as the behavior proof.