Executive Summary
Do not fold this work into JAM-5. Create a new upgrade-test task for a staged OpenClaw upgrade, keep JAM-5 as a later browser-profile cleanup item, and rewrite JAM-5 because its current assumptions are partly wrong.
Current local OpenClaw is 2026.3.13. The latest published stable is 2026.4.9, but it shipped on 2026-04-08 19:41 PDT, with 2026.4.8 published earlier the same day. That is too fresh for Pete's update policy, especially because the 2026.4.x line has had real packaged-install regressions and bundled extension startup regressions reported publicly in issue #61787, issue #62923, and issue #63127. The right move is a pinned, rollback-ready test upgrade, not an unpinned jump to latest.
Recommended path: use 2026.4.1 as the first controlled test target, because it is old enough to have some burn-in and includes relevant browser/CDP and packaged-runtime fixes in release 2026.4.1. After that passes, re-check the 2026.4.9 line after 7 to 14 days of burn-in before testing or adopting it.
1. Problem Statement and Goal
Pete wants to test an OpenClaw upgrade, but not as a loose "update and see what breaks" exercise. The friction is specific:
- Current local install is behind the stable channel.
- The 2026.4.x line has useful fixes, but also recent packaged-install regressions.
- Pete's current browser workflow is still relay-centric in practice, while local docs now prefer
profile="user"for most signed-in browser work and reserveprofile="chrome-relay"for extension attach-tab flows in the browser tool docs and Chrome extension docs. - Existing Mission Control task JAM-5 assumes the upgrade story is simply "remove Browser Relay Check cron jobs and move to CDP." That is too narrow and partly outdated.
Goal: define a staged, exact-version upgrade test plan with pre-checks, validation, rollback, and a clean follow-up task structure.
2. Success Metric
This spec succeeds if Pete can do all of the following without guesswork:
- Name the current version, latest stable, and recommended first test target.
- Run a pinned test upgrade with a prepared rollback path.
- Validate gateway startup, Discord operation, browser profiles, and cron health in under 30 minutes.
- Decide whether to keep, rewrite, or defer JAM-5 based on actual post-upgrade browser behavior.
- Avoid an unpinned jump to a same-day stable release.
3. Current State
Installed/runtime state
- Local installed version: 2026.3.13 from
/opt/homebrew/lib/node_modules/openclaw/package.json. openclaw update status --jsonreports:- install kind: package
- package root:
/opt/homebrew/lib/node_modules/openclaw - channel: stable (default)
- latest stable available: 2026.4.9
~/.openclaw/openclaw.jsonhas:gateway.mode: localgateway.port: 18789- only
channels.discordenabled - no explicit
browsersection - no explicit
updatesection
Browser state
Current runtime browser profiles from openclaw browser profiles --json:
| Profile | Driver | Transport | Running | Notes |
|---|---|---|---|---|
openclaw | openclaw | cdp | no | isolated managed browser |
user | existing-session | chrome-mcp | no | preferred path for signed-in user browser per docs |
chrome-relay | extension | cdp | yes | active today, 7 tabs open |
This matters because Pete's setup is not already living on profile="user". Operationally, it is still using the extension relay.
Local browser-policy drift
The local workspace notes in /Users/vinny/.openclaw/workspace/TOOLS.md still say:
- default profile is
chrome-relay - always use
profile="chrome-relay"for browser actions - relay port is
18792
But current OpenClaw docs say:
- prefer
profile="user"for the user's logged-in browser when existing cookies matter, in the browser docs - use
profile="chrome-relay"only for the Browser Relay extension / toolbar-button attach-tab flow, in the same browser docs and Chrome extension docs
That is a real documentation and workflow mismatch.
Task and cron state
JAM-5 in mission-control/data/tasks.json is currently:
- Title: Browser Relay Cleanup
- Status: backlog
- Priority: low
- Current assumption: after upgrading from 2026.3.11, remove 4 Browser Relay Check cron jobs, update TOOLS.md, update skills using
profile='chrome', runopenclaw doctor --fix
Two problems:
- Current local version is 2026.3.13, not 2026.3.11.
- There are 5 Browser Relay Check cron jobs in
~/.openclaw/cron/jobs.json, not 4.
Relay-related cron jobs currently enabled:
| Name | Schedule |
|---|---|
| Browser Relay Check (5:45am weekdays) | 45 5 * * 1-5 |
| Browser Relay Check (7:45am) | 45 7 * * * |
| Browser Relay Check (11:45am) | 45 11 * * * |
| Browser Relay Check (3:45pm) | 45 15 * * * |
| Browser Relay Check (9pm EOD) | 0 21 * * * |
Skill references that need cleanup later
Current workspace files still reference legacy profile="chrome" usage:
/Users/vinny/.openclaw/workspace/skills/daily-twitter-briefing/SKILL.md/Users/vinny/.openclaw/workspace/skills/linkedin-invites/SKILL.md/Users/vinny/.openclaw/workspace/skills/personal-one-pager/SKILL.md
Those are cleanup items, not reasons to mutate JAM-5 into the whole upgrade plan.
4. Platform Capabilities
OpenClaw supports the relevant pieces natively:
- Version/channel awareness through `openclaw update status`.
- Pinned package-manager upgrades through the workflows in the updating guide.
- Stable vs beta channels in the development channels docs. Stable is the default, which matches Pete's policy.
- Config migration and fixups through `openclaw doctor` and `openclaw doctor --fix`.
- Multiple browser profiles via the browser tool docs, including:
- isolated OpenClaw-managed browser
profile="user"via existing-session / Chrome DevTools MCPprofile="chrome-relay"via the Browser Relay extension- Explicit Chrome extension attach-tab flows via the Chrome extension docs.
Important native behavior change for Pete's setup: the docs no longer treat the extension relay as the default answer for normal user-browser work. That does not mean the relay is gone. It means its scope is narrower.
5. Community Patterns
Public community-visible evidence in early April 2026 points to two patterns.
Pattern A: use exact version pins and be careful with packaged installs
The 2026.4.x line has had real regressions on packaged installs:
- Issue #61787: npm global installs of 2026.4.3 and 2026.4.5 could leave every CLI command broken with missing bundled runtime deps.
- Issue #62923: 2026.4.7 shipped bundled extension
setup-entry.jsspecifiers that referenced missingsrcfiles in the published npm tarball, which could block gateway startup even for disabled channels. - Issue #63127: 2026.4.8 still had missing-module runtime reports on packaged global installs.
- Release 2026.4.8 and release 2026.4.9 are both actively fixing this packaging/runtime class.
Conclusion: people are not treating 2026.4.x as a "blind latest" line. They are pinning exact versions and rolling back when necessary.
Pattern B: prefer user for signed-in browser work, keep chrome-relay for attach-tab cases
The docs moved toward:
profile="user"for existing signed-in Chrome sessions, in the browser docsprofile="chrome-relay"for the extension relay and toolbar-button attach-tab flow, in the Chrome extension docs
That matches the public issue traffic around browser profile migration and existing-session behavior, such as issue #45889 and issue #45812.
ClawHub / Discord community note
I did not capture any useful ClawHub results for this specific upgrade path. Public evidence is good enough to plan around, but not good enough to justify same-day adoption of 2026.4.8 or 2026.4.9.
6. Options
| Option | What it means | Complexity | Reliability | Maintenance | Verdict |
|---|---|---|---|---|---|
| A. Upgrade straight to 2026.4.9 now | Use latest stable immediately | Low | Low | Medium | Wrong fit for Pete. Too fresh, with recent packaged-install churn. |
| B. Staged test on 2026.4.1 first, then re-evaluate latest after burn-in | Pin a known recent stable first, validate browser/profile behavior, then revisit 2026.4.9 after 7 to 14 days | Medium | High | Low | Best fit. Gives new browser semantics and 4.x fixes without same-day risk. |
| C. Stay on 2026.3.13 and only do JAM-5 cleanup | No version move, only browser-relay cleanup | Low | Medium | High | Wrong order. Cleanup assumptions depend on post-upgrade reality. |
Option tradeoffs
- Option A is fast, but it stacks three risks: fresh release, packaged-install regressions in the same release line, and browser workflow drift.
- Option B is one extra step, but it turns the upgrade into a controlled experiment with a clean rollback.
- Option C saves time now, but risks doing cleanup work against the wrong browser model.
7. Recommendation
Choose Option B.
Version recommendation
| Role | Version | Why |
|---|---|---|
| Current local | 2026.3.13 | confirmed installed package |
| Latest published stable | 2026.4.9 | latest stable in registry, published 2026-04-08 19:41 PDT |
| First controlled test target | 2026.4.1 | has 1 week of burn-in, includes relevant packaged-runtime and CDP/profile fixes in release 2026.4.1 |
| Hold for later review | 2026.4.9 | re-check after 7 to 14 days if no fresh packaged-install regressions appear |
Why 2026.4.1 first
- It is not same-day fresh.
- It includes a direct browser/profile fix, `CDP/profiles: prefer cdpPort over stale WebSocket URLs`, which is relevant to a setup that already has both
userandchrome-relayprofiles. - It includes packaged plugin/runtime fixes after the 2026.3.31 externalization change in release 2026.4.1.
- It avoids making Pete the first-day tester of the 2026.4.8 and 2026.4.9 packaging hotfixes.
New task vs modify JAM-5
Create a new task. Do not overload JAM-5.
Reason:
- JAM-5 is a post-upgrade cleanup task.
- This work is an upgrade planning and test-validation task.
- JAM-5 contains stale assumptions: wrong starting version, wrong cron-job count, and an over-strong claim that Browser Relay should simply be removed in favor of CDP.
- If you mutate JAM-5 into the whole upgrade effort, you lose the distinct follow-up cleanup work that still needs to happen after the test.
Recommended relationship:
- New task: staged upgrade test and validation.
- Rewrite JAM-5: browser profile policy cleanup after successful validation.
8. Security Considerations
- Back up before
doctor --fix. The doctor docs allow config rewrites. That is useful, but it means config drift is possible if the fix path changes fields Pete cares about. - Do not use unpinned latest for the first test. Stable-channel default plus no explicit
updateconfig means a loose update command can move farther than intended. - Packaged-install failures can block CLI startup entirely. This is not hypothetical. It is documented in issue #61787 and issue #62923.
- Browser workflow changes can create silent operator friction. If TOOLS.md and skills switch to
profile="user"before Chrome MCP existing-session is actually reliable on this machine, Pete loses working browser automation without a clean fallback. - Do not delete relay checks before proving the relay is no longer required. The extension path still exists in current docs and in the live browser profile list.
9. Implementation Scope
This is research and planning only. No upgrade is executed here.
Files and areas the upgrade task will likely touch later
~/.openclaw/openclaw.json~/.openclaw/cron/jobs.json/Users/vinny/.openclaw/workspace/TOOLS.md/Users/vinny/.openclaw/workspace/skills/daily-twitter-briefing/SKILL.md/Users/vinny/.openclaw/workspace/skills/linkedin-invites/SKILL.md/Users/vinny/.openclaw/workspace/skills/personal-one-pager/SKILL.mdmission-control/data/tasks.jsonfor the new task and JAM-5 rewrite
Concrete upgrade test plan
Pre-upgrade checks
- Capture baseline:
openclaw --versionopenclaw update status --jsonopenclaw gateway statusopenclaw browser profiles --jsonopenclaw browser status --json
- Back up:
~/.openclaw/openclaw.json~/.openclaw/cron/jobs.jsonmission-control/data/tasks.json/Users/vinny/.openclaw/workspace/TOOLS.md- the three affected skill files listed above
- Confirm current relay dependency:
- note whether
chrome-relayis running - note whether
userprofile works at all before upgrade
- Choose a pinned test target, recommended 2026.4.1.
Test upgrade
- Stop the gateway cleanly.
- Upgrade with an exact version pin, using the package-manager flow in the updating guide. Because this install is package-based, do not use an unqualified latest pull.
- Run
openclaw doctor. - Run
openclaw doctor --fixonly after reviewing its proposed fixes. - Restart gateway.
Validation
Run this exact smoke set:
| Test | Pass condition |
|---|---|
| CLI loads | openclaw --version works, no missing-module crash |
| Gateway starts | openclaw gateway status reports healthy start |
| Config still loads | openclaw doctor completes without fatal config read failure |
| Discord channel path survives | no startup crash from bundled channel/plugin loading |
| Browser profiles reconcile | openclaw browser profiles --json still shows openclaw, user, and chrome-relay sensibly |
| Relay path still works | chrome-relay can attach when toolbar badge is on |
| User path works | profile="user" can attach to signed-in Chrome if existing-session handshake is available |
| Cron inventory intact | relay-check jobs still exist until explicitly cleaned up |
Post-upgrade cleanup
Only after validation passes:
- Rewrite
/Users/vinny/.openclaw/workspace/TOOLS.mdso browser guidance matches current docs. - Replace legacy
profile="chrome"instructions in affected skills. - Decide per workflow whether it should use:
profile="user"for signed-in browser work, orprofile="chrome-relay"for attach-tab / toolbar-button flows
- Revisit whether all 5 Browser Relay Check cron jobs are still needed.
- Rewrite JAM-5 to reflect the actual cleanup scope.
Rollback posture
If any of the smoke tests fail:
- Stop gateway.
- Reinstall exact current version: 2026.3.13.
- Restore backed-up config and cron files if
doctor --fixor startup altered them. - Re-run baseline checks until the pre-upgrade state is back.
- Log the failing version and first failing command in Mission Control before retrying.
10. Validation Criteria
The upgrade task should not be called complete unless all of these are true:
- OpenClaw runs on the target pinned version with no missing-module crash.
- Gateway starts cleanly.
- Discord channel boot path is intact.
profile="chrome-relay"still works for extension attach-tab flows.profile="user"is either proven working or explicitly documented as not yet reliable on this machine.- TOOLS.md and affected skill files no longer reference the dead
profile="chrome"name. - JAM-5 is rewritten to match actual post-upgrade cleanup work.
- Rollback to 2026.3.13 has been rehearsed on paper and can be done with exact commands.
11. Category
Behavioral Tweak
Reason: this is primarily a controlled operational change to how Pete upgrades and how browser-profile guidance is expressed. It is not a new external tool or a new skill.
12. Context Loading
For the actual implementation task, load these files in this order:
~/.openclaw/openclaw.jsonat start, to confirm current gateway/channel state.~/.openclaw/cron/jobs.jsonbefore any relay-check cleanup decision.mission-control/data/tasks.jsonbefore editing or creating upgrade tasks./Users/vinny/.openclaw/workspace/TOOLS.mdbefore changing browser guidance.- The three affected skill files only if the task reaches cleanup:
skills/daily-twitter-briefing/SKILL.mdskills/linkedin-invites/SKILL.mdskills/personal-one-pager/SKILL.md
- Local OpenClaw docs first, then public release pages/issues if behavior or regressions need confirmation:
13. Guardrails
- Do not run an unpinned upgrade for the first test.
- Do not delete Browser Relay Check cron jobs before proving they are obsolete.
- Do not rewrite skills to
profile="user"globally unlessuserprofile is verified working on this machine. - Do not assume Browser Relay is removed. Current docs and runtime still expose
chrome-relay. - Do not treat same-day stable releases as production-ready for Pete by default.
- Do not run
openclaw doctor --fixwithout a config backup. - Do not perform the production upgrade inside the planning task.
14. Handoff
Deliverables for Pete:
- This artifact in
/Users/vinny/.openclaw/workspace/artifacts/openclaw_upgrade_test_plan_2026_04_08.md - One new Mission Control task for the staged upgrade test
- One JAM-5 rewrite recommendation for the later browser cleanup
- A simple yes/no readiness call
Recommended Mission Control Task Updates
New task to create
- Title: Stage OpenClaw 2026.4.x upgrade test and validation
- Status: backlog
- Priority: medium
- Suggested description:
```md Run a rollback-ready test upgrade of local OpenClaw from 2026.3.13 to a pinned 2026.4.x target.
Initial test target: 2026.4.1. Latest published stable to monitor: 2026.4.9.
Steps
- Capture baseline status, browser profiles, cron inventory, and current version.
- Back up ~/.openclaw/openclaw.json, ~/.openclaw/cron/jobs.json, TOOLS.md, affected skill files, and tasks.json.
- Upgrade to pinned target version.
- Run openclaw doctor, then doctor --fix if needed.
- Validate gateway startup, Discord boot path, browser profiles, chrome-relay attach, and user-profile attach.
- If validation fails, roll back to 2026.3.13 and log first failing command.
- If validation passes, hand off browser-profile cleanup to JAM-5.
```
JAM-5 recommendation
Keep JAM-5, but rewrite it.
- New title: Reconcile browser profile defaults after OpenClaw upgrade
- Status: backlog
- Priority: low
- Suggested description:
```md After a successful OpenClaw 2026.4.x upgrade test, reconcile local browser guidance with current OpenClaw browser semantics.
Steps
- Update TOOLS.md browser guidance so it no longer treats chrome-relay as the default for all browser work.
- Replace legacy profile="chrome" references in daily-twitter-briefing, linkedin-invites, and personal-one-pager.
- Decide which workflows should use profile="user" versus profile="chrome-relay".
- Reassess whether the 5 Browser Relay Check cron jobs are still needed.
- Run openclaw doctor --fix only if config migration or validation requires it.
```
Ready for Review
Yes. Latest release status is clear, current local version is clear, and the main uncertainty is not discovery. It is burn-in. That is already accounted for in the recommendation.