openclaw - 💡(How to fix) Fix [Bug]: `openclaw security audit` can hang with no output while the installed `runSecurityAudit(...)` path completes [1 comments, 2 participants]

Summary

On OpenClaw 2026.4.29 installed via global npm on Linux, both:

openclaw security audit
openclaw security audit --deep

can appear to hang silently with no output for a long time.

This does not look like an audit-core failure. In the same install, direct invocation of the installed runSecurityAudit(...) path completed successfully in local testing (~16.3s full-default; faster in narrower variants).

The stronger hypothesis is that the CLI command path reaches the same synchronous plugin-runtime / plugin-registry loading regression family already reported elsewhere, rather than a separate security audit engine bug.

Likely related upstream issues:

• #73532 — plugin loader hot loop / bundled runtime mirror / manifest parsing
• #74860 — synchronous plugin registry rebuilds during tool creation
• #75069 — bundled plugin runtime mirror blocks main thread for tens of seconds
• related symptom family: #72338, #74971

Environment

• OpenClaw: 2026.4.29
• Install method: global npm
• Package root: ~/.npm-global/lib/node_modules/openclaw
• OS: Linux x86_64

Actual behavior

• openclaw security audit can sit with no visible output and not complete promptly.
• openclaw security audit --deep shows the same symptom.
• From the operator side, the command looks hung.

Expected behavior

openclaw security audit should either:

• complete and print findings, or
• fail with a clear error,

but it should not sit silently looking hung.

Evidence that the audit core itself is still working

In the same installed build, direct local testing of the installed audit path succeeded:

• runSecurityAudit(...) full-default: ~16.3s
• narrower variants: ~5.1s and ~6.7s
• SecretRef gateway resolution: ~4ms

So this looks much less like a failure inside the core audit logic and much more like a problem in the CLI/plugin-loading path around it.

Installed-code path that makes this look related to the plugin/runtime regression cluster

1) CLI command calls runSecurityAudit(...)

Installed file:

• dist/security-cli-CGNqeDBZ.js

Path:

• .command("audit")
• resolveCommandSecretRefsViaGateway(...)
• runSecurityAudit({...})

2) runSecurityAudit(...) calls plugin security collector loading

Installed file:

• dist/audit-BUnh7jdS.js

Path:

• findings.push(...await collectPluginSecurityAuditFindings(context));

3) Plugin security collectors are enabled by default in audit context

Installed file:

• dist/audit-BUnh7jdS.js

Path:

• loadPluginSecurityCollectors: opts.loadPluginSecurityCollectors !== false

4) When collectors are not already active, audit loads a plugin metadata snapshot

Installed file:

• dist/audit-BUnh7jdS.js

Path:

• loadPluginMetadataRegistrySnapshot({...}).securityAuditCollectors

5) Metadata snapshot loading explicitly uses cache: false

Installed file:

• dist/metadata-registry-loader-BWbuUMq-.js

Relevant code:

function loadPluginMetadataRegistrySnapshot(options) {
  return loadOpenClawPlugins(buildPluginRuntimeLoadOptions(resolvePluginRuntimeLoadContext(options), {
    throwOnLoadError: true,
    cache: false,
    activate: false,
    mode: "validate",
    loadModules: options?.loadModules,
    ...hasExplicitPluginIdScope(options?.onlyPluginIds) ? { onlyPluginIds: options?.onlyPluginIds } : {}
  }));
}

That looks important given the existing upstream reports about repeated synchronous plugin/runtime/registry work.

6) The installed build still contains synchronous public-artifact / runtime-root preparation paths

Installed files:

• dist/public-surface-loader-3_rjjOTW.js
• dist/bundled-runtime-root-CCm_zSck.js

Relevant functions:

• loadBundledPluginPublicArtifactModuleSync(params)
• prepareBundledPluginRuntimeRoot(params)

Those appear to be the same general class of synchronous plugin-runtime loading behavior already implicated in the open regression cluster.

Why I think this is related, not a separate audit-engine bug

The combination below seems too strong to ignore:

1. the internal audit path completes,
2. the CLI path still triggers plugin security collector loading,
3. that path can load plugin metadata snapshots with cache: false,
4. the installed build still contains synchronous runtime/public-artifact preparation functions,
5. upstream already has multiple open reports for synchronous plugin/runtime/registry work causing stalls, timeouts, or apparent hangs.

So openclaw security audit hang/no-output may be another entry point into the same regression family.

Suggested maintainer checks

1. Check whether security audit should really use uncached plugin metadata snapshot loading on this CLI path.
2. Verify whether collectPluginSecurityAuditFindings(...) can trigger synchronous bundled runtime preparation or public-surface loading in 2026.4.29.
3. Compare this path directly against the fixes/work around:
   • #73532
   • #74860
   • #75069
4. Consider early progress output, warning output, or timeout handling for slow plugin collector loading so the CLI does not look frozen.

Additional note

2026.4.29 changelog already mentions a partial-looking mitigation:

• "Plugins/runtime deps: reuse unchanged bundled plugin runtime mirrors instead of rebuilding plugin trees on every load, cutting avoidable writes and restart/reconnect I/O on slow storage. Fixes #72933."

But on this install, the security audit command path still appears to reach synchronous plugin/runtime preparation code, so this may be only partially mitigated for this entry point.

If useful, I can provide

• exact local command timings already collected
• exact installed-file line references for the call path above
• a minimized repro script that compares direct installed runSecurityAudit(...) invocation versus the CLI wrapper