Bug type
Crash / restart-handoff failure
Beta release blocker
No
Summary
On macOS with a LaunchAgent-managed gateway and npm-installed OpenClaw, a managed update can stop the gateway and then fail the restart handoff because the spawned openclaw update --yes process crashes with Error: ENOENT: no such file or directory, uv_cwd.
The visible result is a managed-service-handoff-failed / Gateway restart update error (npm) notification even though openclaw update status may later report the install is already up to date.
This looks related to the general uv_cwd bug in #73676, but here it breaks the managed update/restart path itself rather than only an interactive CLI command.
Steps to reproduce
- Run OpenClaw on macOS as a LaunchAgent-managed gateway.
- Install OpenClaw globally via npm/pnpm-style CLI install.
- Trigger a managed update/restart flow that runs
openclaw update --yes from the gateway side.
- Observe the restart handoff fail after the LaunchAgent is stopped.
I do not yet have a minimal standalone repro for the exact cwd state inside the managed update helper, but the production handoff log below shows the failure clearly.
Expected behavior
Managed update should either:
- sanitize/fallback the working directory before invoking the updater, or
- refuse the handoff safely before stopping the LaunchAgent.
In either case, it should not stop the service and then crash on uv_cwd.
Actual behavior
The managed update helper starts openclaw update --yes, stops the LaunchAgent, and then the updater crashes immediately with:
Error: ENOENT: no such file or directory, uv_cwd
The user receives a restart/update error notification:
Gateway restart update error (npm)
Reason: managed-service-handoff-failed
At the same time, openclaw update status can report:
Install pnpm
Channel stable (default)
Update pnpm · up to date · npm latest 2026.5.18
OpenClaw version
2026.5.18
Operating system
macOS
Install method
npm / pnpm-managed global install
Model
NOT_RELEVANT
Provider / routing chain
NOT_RELEVANT
Additional provider/model setup details
NOT_RELEVANT
Logs, screenshots, and evidence
Managed handoff log:
[2026-05-18T23:28:59.261Z] starting managed update command: openclaw update --yes
[2026-05-18T23:28:59.262Z] managed update command pid=51881
Stopped LaunchAgent: gui/501/ai.openclaw.gateway
node:internal/bootstrap/switches/does_own_process_state:142
cachedCwd = rawMethods.cwd();
^
Error: ENOENT: no such file or directory, uv_cwd
at process.wrappedCwd [as cwd] (node:internal/bootstrap/switches/does_own_process_state:142:28)
at isMainModule (file:///opt/homebrew/lib/node_modules/openclaw/dist/is-main-myFrAEl9.js:13:92)
at file:///opt/homebrew/lib/node_modules/openclaw/dist/index.js:38:16
at ModuleJob.run (node:internal/modules/esm/module_job:343:25)
at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:665:26)
at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:117:5) {
errno: -2,
code: 'ENOENT',
syscall: 'uv_cwd'
}
Node.js v22.22.2
[2026-05-18T23:29:18.476Z] managed update command exited code=1 signal=null
Persistent handoff marker left behind after the failure:
{"kind":"gateway-supervisor-restart-handoff","version":1,"intentId":"5ddc42fb-81c4-4c66-84fa-084cefbb8b0f","pid":51435,"processInstanceId":"08729a78-0e23-40c9-b62e-dfaf6ce76f38","createdAt":1779146937662,"expiresAt":1779146997662,"reason":"update.run","source":"gateway-update","restartKind":"update-process","supervisorMode":"launchd"}
Impact and severity
Affected: macOS LaunchAgent-managed gateways using managed self-update
Severity: High for operator trust / availability
Frequency: Seen in production during update
Consequence: The update channel reports a failed managed handoff after the service stop, leaving the operator unsure whether the gateway is healthy and whether the update actually succeeded.
Additional information
openclaw doctor --non-interactive completes without surfacing this handoff failure.
openclaw doctor --fix --non-interactive also does not clear or explain the failed restart handoff state.
- This seems adjacent to both:
Suggested fix
- In the managed update/restart path, resolve
process.cwd() defensively before stopping the LaunchAgent.
- If cwd lookup fails, fall back to a stable directory such as the user home or package root before invoking the CLI entrypoint.
- Treat
uv_cwd during managed update as a first-class, user-visible recovery case with a concrete repair message.
- Add an integration test for macOS LaunchAgent managed updates where the initiating process has an invalid cwd.
Bug type
Crash / restart-handoff failure
Beta release blocker
No
Summary
On macOS with a LaunchAgent-managed gateway and npm-installed OpenClaw, a managed update can stop the gateway and then fail the restart handoff because the spawned
openclaw update --yesprocess crashes withError: ENOENT: no such file or directory, uv_cwd.The visible result is a
managed-service-handoff-failed/Gateway restart update error (npm)notification even thoughopenclaw update statusmay later report the install is already up to date.This looks related to the general
uv_cwdbug in #73676, but here it breaks the managed update/restart path itself rather than only an interactive CLI command.Steps to reproduce
openclaw update --yesfrom the gateway side.I do not yet have a minimal standalone repro for the exact cwd state inside the managed update helper, but the production handoff log below shows the failure clearly.
Expected behavior
Managed update should either:
In either case, it should not stop the service and then crash on
uv_cwd.Actual behavior
The managed update helper starts
openclaw update --yes, stops the LaunchAgent, and then the updater crashes immediately with:The user receives a restart/update error notification:
At the same time,
openclaw update statuscan report:OpenClaw version
2026.5.18
Operating system
macOS
Install method
npm / pnpm-managed global install
Model
NOT_RELEVANT
Provider / routing chain
NOT_RELEVANT
Additional provider/model setup details
NOT_RELEVANT
Logs, screenshots, and evidence
Managed handoff log:
Persistent handoff marker left behind after the failure:
{"kind":"gateway-supervisor-restart-handoff","version":1,"intentId":"5ddc42fb-81c4-4c66-84fa-084cefbb8b0f","pid":51435,"processInstanceId":"08729a78-0e23-40c9-b62e-dfaf6ce76f38","createdAt":1779146937662,"expiresAt":1779146997662,"reason":"update.run","source":"gateway-update","restartKind":"update-process","supervisorMode":"launchd"}Impact and severity
Affected: macOS LaunchAgent-managed gateways using managed self-update
Severity: High for operator trust / availability
Frequency: Seen in production during update
Consequence: The update channel reports a failed managed handoff after the service stop, leaving the operator unsure whether the gateway is healthy and whether the update actually succeeded.
Additional information
openclaw doctor --non-interactivecompletes without surfacing this handoff failure.openclaw doctor --fix --non-interactivealso does not clear or explain the failed restart handoff state.uv_cwdwhen cwd disappears)Suggested fix
process.cwd()defensively before stopping the LaunchAgent.uv_cwdduring managed update as a first-class, user-visible recovery case with a concrete repair message.