What Problem This Solves
When the CLI encounters an error displaying root help in the fast path, the error handler sets process.exitCode = 1 but does not explicitly call process.exit(1). Because it's a fast path that skips the main runtime teardown, any dangling promises, open file descriptors, or active timers will cause the Node event loop to stay open, hanging the CLI indefinitely instead of returning to the user's terminal.
Expected vs Actual Behavior
Expected: The error handler should explicitly terminate the process or ensure the event loop is fully drained.
Actual: It only sets the exit code, relying on a naturally empty event loop which is not guaranteed.
Code Link
https://github.com/openclaw/openclaw/blob/main/src/entry.ts#L155-L163
Proposed Solution
Update the error handler in deps.onError to explicitly call process.exit(1) after logging the error, or utilize the
untime.exit(1) standard.
What Problem This Solves
When the CLI encounters an error displaying root help in the fast path, the error handler sets process.exitCode = 1 but does not explicitly call process.exit(1). Because it's a fast path that skips the main runtime teardown, any dangling promises, open file descriptors, or active timers will cause the Node event loop to stay open, hanging the CLI indefinitely instead of returning to the user's terminal.
Expected vs Actual Behavior
Expected: The error handler should explicitly terminate the process or ensure the event loop is fully drained.
Actual: It only sets the exit code, relying on a naturally empty event loop which is not guaranteed.
Code Link
https://github.com/openclaw/openclaw/blob/main/src/entry.ts#L155-L163
Proposed Solution
Update the error handler in deps.onError to explicitly call process.exit(1) after logging the error, or utilize the
untime.exit(1) standard.