PR #66102: fix(build): pin subagent-registry.runtime as stable entry (#66096)

• Repository: openclaw/openclaw
• Author: WuKongAI-CMU
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/66102

Description (problem / solution / changelog)

Summary

`[email protected]` ships without `dist/subagent-registry.runtime.js`, but the built `src/agents/subagent-registry.ts` still does `import("./subagent-registry.runtime.js")` at runtime. Subagent cleanup then fails with `ERR_MODULE_NOT_FOUND` on every run (#66096):

``` Cannot find module '.../dist/subagent-registry.runtime.js' imported from '.../dist/subagent-registry-CflSFWBm.js' ```

`tsdown.config.ts` already maintains an explicit allowlist of lazy runtime boundaries that must be emitted on stable filenames so the downstream `writeStableRootRuntimeAliases` postbuild step (in `scripts/runtime-postbuild.mjs`) can generate the `*.runtime.js` re-export shim. The `subagent-registry` runtime was missing from that list, so tsdown folded it into an adjacent hashed chunk (`subagent-registry-<hash>.js`) and the shim generator had nothing matching `<base>.runtime-<hash>.js` to alias from.

This PR adds `agents/subagent-registry.runtime` to the entries block alongside the other `agents/*.runtime` boundaries (`auth-profiles`, `model-catalog`, `models-config`, etc.) so the built tree contains both `dist/agents/subagent-registry.runtime-<hash>.js` and `dist/subagent-registry.runtime.js` going forward.

This matches the pattern used for the previous missing-runtime fixes referenced in the issue: #65561, #65735, #65962.

Closes #66096.

Changes

• `tsdown.config.ts` — add `"agents/subagent-registry.runtime": "src/agents/subagent-registry.runtime.ts"` to `buildCoreDistEntries()` alphabetically next to the other `agents/` runtime entries (1-line insertion)

Test plan

• Mirrors the existing pattern for `auth-profiles.runtime`, `model-catalog.runtime`, `models-config.runtime`, which all currently ship correctly
• Source file `src/agents/subagent-registry.runtime.ts` already exists
• The only runtime caller (`src/agents/subagent-registry.ts:121`) uses the `./subagent-registry.runtime.js` relative path which the stable-alias postbuild step resolves
• A CI build-smoke that greps `dist/` for `subagent-registry.runtime.js` would catch similar regressions — can be a follow-up, not included here to keep the diff minimal

🤖 Generated with Claude Code

Changed files

• tsdown.config.ts (modified, +1/-0)

---

PR #66276: fix(cli): prevent process hang after gateway RPC commands (#66227)

• Repository: openclaw/openclaw
• Author: lml2468
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/66276

Description (problem / solution / changelog)

Summary

Fixes #66227 — CLI commands (cron list, agents list, etc.) hang indefinitely after printing their result.

Root cause: executeGatewayRequestWithScopes calls client.stop() (fire-and-forget) after the RPC response arrives. This issues ws.close() but does not wait for the server's close frame. The underlying TCP socket remains ref'd until either the server responds or the 250 ms ws.terminate() grace timer fires. Since runCli() returns without process.exit(), any handle that outlives the command stalls the event loop indefinitely.

The regression in 2026.4.12 likely widened this window (Gateway-side close behavior change, tick interval change, or new ref'd handles introduced in that release).

Changes

src/cli/run-main.ts

Add process.exit(process.exitCode ?? 0) at the end of runCli(), after closeCliMemoryManagers() completes in the finally block.

• All async cleanup runs before the call
• process.once('exit', ...) handlers are synchronous and still fire normally (verified: finalizeDebugProxyCapture is sync)
• Makes CLI exit deterministic regardless of which handles outlive the command

src/gateway/client.ts

Call tickTimer.unref() immediately after the setInterval in startTickWatch().

• beginStop() already calls clearInterval(tickTimer) on the normal close path — this is unchanged
• unref() is defence-in-depth for any path where clearInterval is not reached before the process would otherwise exit naturally (e.g. uncaught error before beginStop)
• No effect on the Gateway server process (server has its own lifecycle management)

Safety analysis

• process.once('exit') in run-main.ts (line 178): calls finalizeDebugProxyCapture() — synchronous SQLite flush + fetch patch removal. Fires correctly via process.exit(). ✅
• No other process.on('exit') or process.on('beforeExit') registrations found in src/cli/. ✅
• stopAndWait() was considered and rejected: awaiting a close-frame-dependent promise inside onHelloOk's callback stack has awkward timing and is redundant given the process.exit() in runCli(). ✅

Testing

Manual verification: openclaw cron list and openclaw agents list exit immediately after output. No behaviour change for error paths (already called process.exit(1)).

AI Disclosure

• AI-assisted (Claude Code via OpenClaw)
• Root cause traced through full call chain: runCli → program.parseAsync → callGatewayFromCli → executeGatewayRequestWithScopes → GatewayClient
• Exit handler audit performed before adding process.exit()
• Understands what the code does — minimal targeted fix, no architecture change

Changed files

• src/entry.ts (modified, +5/-1)
• src/gateway/client.ts (modified, +5/-0)
• src/index.ts (modified, +8/-5)
• src/infra/exit-after-flush.ts (added, +28/-0)