Summary

The hourly auto-updater fires correctly but every attempt fails because the spawned child openclaw update --yes inherits OPENCLAW_SERVICE_MARKER / OPENCLAW_SERVICE_KIND from its launchd-managed gateway parent. The package-update guard in update-command.ts then refuses with Package updates cannot run from inside the gateway service process., so the gateway is stuck on whichever version was installed when launchd last (re)started it.

Net effect on macOS / launchd npm installs: update.auto.enabled = true is effectively a no-op once the gateway is running as a launchd service.

Reproduction

1. Install OpenClaw via npm globally.
2. Run as a launchd service (the standard openclaw daemon install path); confirm the plist sets OPENCLAW_SERVICE_MARKER=openclaw and OPENCLAW_SERVICE_KIND=gateway in EnvironmentVariables.
3. Set update.auto.enabled = true (and any non-zero stable/beta delay) in openclaw.json.
4. Have a newer published version available. Wait for the rollout window to expire.
5. Watch ~/.openclaw/logs/gateway.log:

[gateway] auto-update attempt failed

1. Reproduce manually from inside any process the gateway spawned (or just inherit the same env):

$ openclaw update --dry-run    # reports the new version is available
$ openclaw update --yes
Package updates cannot run from inside the gateway service process.
$ echo $?
1

1. Strip the markers and the same command succeeds:

$ env -u OPENCLAW_SERVICE_MARKER -u OPENCLAW_SERVICE_KIND openclaw update --yes
# updates cleanly

Expected behavior

The auto-updater's spawned child should be able to perform a package update — that's the entire point of runAutoUpdateCommand. The guard exists to stop a user/operator from running openclaw update from inside the live gateway process, not to block the gateway's own auto-update flow.

Actual behavior

runAutoUpdateCommand (in src/infra/update-startup.ts) sets only OPENCLAW_AUTO_UPDATE=1 on the spawned child's env override. resolveCommandEnv merges that on top of process.env, which still contains the launchd-injected markers. The guard shouldBlockPackageUpdateFromGatewayServiceEnv → isRunningInsideGatewayService then returns true and the child exits with the "Package updates cannot run from inside the gateway service process." error before the install starts.

Root cause file pointers

• Auto-update child spawn: src/infra/update-startup.ts → runAutoUpdateCommand (~L233). Currently passes env: { OPENCLAW_AUTO_UPDATE: "1" } only, so OPENCLAW_SERVICE_MARKER and OPENCLAW_SERVICE_KIND are inherited from the gateway's process env.
• Guard that refuses the update: src/cli/update-cli/update-command.ts → isRunningInsideGatewayService (~L580) and shouldBlockPackageUpdateFromGatewayServiceEnv (~L589), invoked at ~L2249 with the "Package updates cannot run from inside the gateway service process." error.
• Marker source: src/daemon/service-env.ts (~L415) sets OPENCLAW_SERVICE_MARKER: GATEWAY_SERVICE_MARKER and OPENCLAW_SERVICE_KIND: GATEWAY_SERVICE_KIND in the launchd plist's EnvironmentVariables.
• Existing helper that already does the right thing for sibling code paths: stripGatewayServiceMarkerEnv in update-command.ts (~L688).

Workaround

We've been wrapping the (separate) skills updater with env -u OPENCLAW_SERVICE_MARKER -u OPENCLAW_SERVICE_KIND openclaw update --yes … and running the package update manually that way. That works but the built-in update.auto.enabled flow can't reach it.

Proposed fix

In runAutoUpdateCommand, drop the markers (and keep the existing positive OPENCLAW_AUTO_UPDATE=1 signal) when constructing the spawn env override. With the current resolveCommandEnv semantics, setting a key to undefined in the override is enough — it gets filtered out before the spawn:

env: {
  OPENCLAW_AUTO_UPDATE: "1",
  OPENCLAW_SERVICE_MARKER: undefined,
  OPENCLAW_SERVICE_KIND: undefined,
},

PR following.

Environment

• OpenClaw 2026.5.4 → 2026.5.5 (also reproduced on earlier 2026.5.x).
• macOS, Apple Silicon, npm install via npm i -g openclaw, gateway running as a user launchd agent.
• Logs: hourly [gateway] auto-update attempt failed in ~/.openclaw/logs/gateway.log; manual openclaw update --yes fails with the guard error from any child of the gateway; env -u … strip succeeds.