Move a Git checkout back to the normal stable update workflow

Troubleshooting
, , , ,
1

Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

My OpenClaw installation appears to be a Git checkout with no upstream branch. I have been fetching tags and rebuilding with pnpm for every update. How can I return to the normal low-maintenance stable update flow without losing state?

2

First identify the install without changing it:

openclaw --version
openclaw update status --json
openclaw update --dry-run --json

A pnpm command alone does not prove a source checkout. The update dry run reports the install kind and whether a channel change would switch it to package management.

3

The dry run confirms installKind: git and an effective dev channel. My checkout is on a custom branch at a release tag with no upstream.

4

That is the correct distinction. Preview the stable conversion and review every reported action:

openclaw update --channel stable --dry-run --json

On current OpenClaw, stable is a supported package channel and the dry run should indicate whether the Git checkout will switch installation mode. Create a verified backup and ensure the tree is clean before applying. Leave the checkout in place until the package install and Gateway are verified.

5

My systemd service points directly into the Git checkout. Will the conversion update that command, or do I need to edit the unit myself?

6

If OpenClaw created the service, the updater can regenerate it. A hand-written or externally supervised unit may remain unchanged. Check openclaw gateway status --deep --json before and after conversion. If the service still points to the checkout, use openclaw gateway install --force from the new intended CLI rather than editing the unit manually. Keep the old checkout until the service command, version, and connectivity probe all agree.

7

Also inspect systemd drop-ins because they can override a regenerated unit. An older package in another prefix should remain untouched until the new installation is proven.