openclaw - 💡(How to fix) Fix [Meta] Critical performance & reliability: startup latency, TUI responsiveness, agent blocking, and Windows upgrade stability [2 comments, 2 participants]

Summary

OpenClaw's startup latency, TUI responsiveness, agent task blocking, and Windows upgrade reliability have degraded to a point that severely impacts daily usability. This issue consolidates four critical areas that need immediate attention before any new features are added.

1. Excessive Startup Latency — Gateway Should Be Lightweight

Problem

The TUI takes 2+ minutes to establish a connection and become responsive. The gateway bootstrap loads everything upfront: all plugins, all skills, session migrations, subagent registry, manifest lookups, and channel maintenance — before the user can even type a message.

Relevant startup path:

• src/tui/tui.ts → runTui() → loads runtime config, resolves agent ID, creates backend
• src/gateway/server.impl.ts → startGatewayServer() → phased bootstrap including full plugin discovery and loading
• src/plugins/loader.ts → discoverOpenClawPlugins() → JITI transpilation, manifest validation, registry building

Suggestion

• Fast-path startup: The gateway should bind the network listener and confirm connection to the TUI immediately, then defer non-essential initialization to background tasks.
• Lazy/dynamic loading: Plugins and skills should be loaded on-demand based on context, not all at boot time. The createLazyRuntimeModule() pattern already exists in src/plugins/runtime/index.ts — extend it to cover plugin discovery and skill registration.
• Target: TUI should acknowledge connection and provide basic API service within < 5 seconds.

2. TUI Performance — Primary Interface Needs Optimization

Problem

The TUI is the primary interface for local use (alongside the browser control UI), yet its startup and connection process is unacceptably slow. Every second spent waiting for the TUI to connect is a second of user frustration.

Suggestion

• Separate the TUI connection handshake from the full bootstrap. The TUI should render immediately with a "connecting" state, then progressively enable features as they become available.
• Consider a lightweight embedded mode that doesn't require a full gateway server for single-user local sessions.
• Profile the runTui() → EmbeddedTuiBackend / GatewayChatClient initialization path to identify the biggest time sinks.

3. Main Agent Blocking — Background Tasks Starve User Interaction

Problem

There is no separation between the interactive agent and background task agents. When a background task is running (e.g., a long-running subagent, cron job, or auto-reply), the main process becomes completely unresponsive to user input. All messages queue up and only get processed after the background task completes.

Relevant code:

• src/auto-reply/reply/agent-runner.ts → runReplyAgent() runs inline, blocking the event loop
• src/tasks/task-registry.ts → single-process model, no task prioritization or scheduling isolation
• No "main agent" that handles user interaction separately from background workers

Suggestion

• Introduce a dedicated main agent responsible for user interaction and task dispatch. This agent should never be blocked by background work.
• Implement task queuing with prioritization: user-facing messages get highest priority; background tasks run in isolated workers or sub-processes.
• Consider a multi-process or worker-thread model where background agent turns don't share the same event loop as the interactive TUI session.

4. Windows Upgrade Reliability — Gateway Often Fails to Start After Update

Problem

Multiple users report that after upgrading on Windows, the gateway fails to start entirely. This is likely related to:

• Windows-specific path handling (realpathSync.native failures, path case sensitivity)
• Port/PID detection via PowerShell Get-NetTCPConnection timing out or returning stale results (src/infra/windows-port-pids.ts)
• .cmd/.bat spawn options requiring { shell: true } (src/tui/tui.ts → resolveLocalAuthSpawnOptions)
• File locks held by the previous gateway process during upgrade
• Config or state migration incompatibilities on Windows

Suggestion

• Add a post-upgrade health check that verifies the gateway can start cleanly before marking the upgrade as successful.
• Ensure proper process cleanup on Windows before replacing binaries (force-close old gateway, wait for port release).
• Test the upgrade path as a first-class CI scenario on Windows, not just as an afterthought.
• Provide a clear rollback mechanism when an upgrade corrupts the gateway state.

Priority

These are not feature requests — they are usability blockers. The recommendation is:

1. Pause all new feature development until these four areas are addressed.
2. Focus on making OpenClaw fast, responsive, and reliable before making it more capable.
3. Treat Windows as a first-class platform, not a secondary target.

Impact

• Users waiting 2+ minutes for every TUI session
• User messages silently queuing behind background tasks with no feedback
• Windows users unable to start the gateway after routine upgrades
• Growing frustration and churn among the user base

A fast, reliable, lightweight gateway with responsive TUI and non-blocking agent handling is the foundation that everything else builds on. Without it, no amount of new features will compensate for the degraded core experience.