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 reserve profile="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:

1. Name the current version, latest stable, and recommended first test target.
2. Run a pinned test upgrade with a prepared rollback path.
3. Validate gateway startup, Discord operation, browser profiles, and cron health in under 30 minutes.
4. Decide whether to keep, rewrite, or defer JAM-5 based on actual post-upgrade browser behavior.
5. 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 --json reports:
• install kind: package
• package root: /opt/homebrew/lib/node_modules/openclaw
• channel: stable (default)
• latest stable available: 2026.4.9
• ~/.openclaw/openclaw.json has:
• gateway.mode: local
• gateway.port: 18789
• only channels.discord enabled
• no explicit browser section
• no explicit update section

Browser state

Current runtime browser profiles from openclaw browser profiles --json:

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', run openclaw doctor --fix

Two problems:

1. Current local version is 2026.3.13, not 2026.3.11.
2. There are 5 Browser Relay Check cron jobs in ~/.openclaw/cron/jobs.json, not 4.

Relay-related cron jobs currently enabled:

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 MCP
• profile="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.js specifiers that referenced missing src files 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 docs
• profile="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 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

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 user and chrome-relay profiles.
• 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:

1. New task: staged upgrade test and validation.
2. 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 update config 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.md
• mission-control/data/tasks.json for the new task and JAM-5 rewrite

Concrete upgrade test plan

Pre-upgrade checks

1. Capture baseline:

• openclaw --version
• openclaw update status --json
• openclaw gateway status
• openclaw browser profiles --json
• openclaw browser status --json

1. Back up:

• ~/.openclaw/openclaw.json
• ~/.openclaw/cron/jobs.json
• mission-control/data/tasks.json
• /Users/vinny/.openclaw/workspace/TOOLS.md
• the three affected skill files listed above

1. Confirm current relay dependency:

• note whether chrome-relay is running
• note whether user profile works at all before upgrade

1. Choose a pinned test target, recommended 2026.4.1.

Test upgrade

1. Stop the gateway cleanly.
2. 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.
3. Run openclaw doctor.
4. Run openclaw doctor --fix only after reviewing its proposed fixes.
5. Restart gateway.

Validation

Run this exact smoke set:

Post-upgrade cleanup

Only after validation passes:

1. Rewrite /Users/vinny/.openclaw/workspace/TOOLS.md so browser guidance matches current docs.
2. Replace legacy profile="chrome" instructions in affected skills.
3. Decide per workflow whether it should use:

• profile="user" for signed-in browser work, or
• profile="chrome-relay" for attach-tab / toolbar-button flows

1. Revisit whether all 5 Browser Relay Check cron jobs are still needed.
2. Rewrite JAM-5 to reflect the actual cleanup scope.

Rollback posture

If any of the smoke tests fail:

1. Stop gateway.
2. Reinstall exact current version: 2026.3.13.
3. Restore backed-up config and cron files if doctor --fix or startup altered them.
4. Re-run baseline checks until the pre-upgrade state is back.
5. 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:

1. ~/.openclaw/openclaw.json at start, to confirm current gateway/channel state.
2. ~/.openclaw/cron/jobs.json before any relay-check cleanup decision.
3. mission-control/data/tasks.json before editing or creating upgrade tasks.
4. /Users/vinny/.openclaw/workspace/TOOLS.md before changing browser guidance.
5. The three affected skill files only if the task reaches cleanup:

• skills/daily-twitter-briefing/SKILL.md
• skills/linkedin-invites/SKILL.md
• skills/personal-one-pager/SKILL.md

1. Local OpenClaw docs first, then public release pages/issues if behavior or regressions need confirmation:

• updating guide
• development channels
• update CLI docs
• doctor CLI docs
• browser docs
• Chrome extension docs

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 unless user profile 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 --fix without a config backup.
• Do not perform the production upgrade inside the planning task.

14. Handoff

Deliverables for Pete:

1. This artifact in /Users/vinny/.openclaw/workspace/artifacts/openclaw_upgrade_test_plan_2026_04_08.md
2. One new Mission Control task for the staged upgrade test
3. One JAM-5 rewrite recommendation for the later browser cleanup
4. 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

1. Capture baseline status, browser profiles, cron inventory, and current version.
2. Back up ~/.openclaw/openclaw.json, ~/.openclaw/cron/jobs.json, TOOLS.md, affected skill files, and tasks.json.
3. Upgrade to pinned target version.
4. Run openclaw doctor, then doctor --fix if needed.
5. Validate gateway startup, Discord boot path, browser profiles, chrome-relay attach, and user-profile attach.
6. If validation fails, roll back to 2026.3.13 and log first failing command.
7. 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

1. Update TOOLS.md browser guidance so it no longer treats chrome-relay as the default for all browser work.
2. Replace legacy profile="chrome" references in daily-twitter-briefing, linkedin-invites, and personal-one-pager.
3. Decide which workflows should use profile="user" versus profile="chrome-relay".
4. Reassess whether the 5 Browser Relay Check cron jobs are still needed.
5. 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.