openwork-server.exe processes not terminated after closing window, causing memory accumulation on Windows

[sandywzj2020]

Bug: openwork-server.exe processes not terminated after closing window, causing memory accumulation on Windows

Environment

Item	Details
OS	Windows 10 (19045)
OpenWork version	Installed 2025-02-04
Install path	C:\Program Files\OpenWork\ (~375 MB)
Workspace	Starter (local)

Problem

Every time a new session/tab is opened in OpenWork, a new openwork-server.exe process is spawned. However, when the corresponding UI window/tab is closed, the server process does not exit — it keeps running in the background and listening on its assigned port. Over time, these zombie processes accumulate, causing:

• Continuous memory growth (each instance consumes ~100–137 MB)
• In a single day, 4 processes accumulated, totaling ~476 MB of wasted memory
• Overall system slowdown and degraded OpenWork performance

Steps to Reproduce

1. Start OpenWork
2. Observe openwork-server.exe process (tasklist | findstr openwork-server), note the PID
3. Close the OpenWork main window
4. Check processes again — openwork-server.exe is still running
5. Repeat open/close cycles — each time a new server process is added

Observed Behavior

PID     Memory      Started    Port
18232   ~137 MB     08:15      8787
25976   ~100 MB     15:05      50769
15316   ~117 MB     15:07      51467
16716   ~112 MB     15:22      57375

All 4 processes point to the same workspace (workspaces\starter), each using a different token and port. Old instances are never reused or cleaned up.

Expected Behavior

• When the OpenWork window/tab is closed, the corresponding openwork-server.exe process should exit.
• Alternatively, implement a singleton pattern: detect existing server instances and reuse them rather than spawning new ones each time.
• At minimum, clean up stale processes for the same workspace before starting a new instance.

Additional Findings

1. Audit log confirms no reuse — audit.jsonl shows a different tokenHash on each launch, confirming each session creates a brand-new server instance with no reuse mechanism.

2. owpenbot WhatsApp bridge stuck in reconnect loop — owpenbot.log shows WebSocket connection to wss://web.whatsapp.com/ws/chat failing, retrying 11 times with increasing backoff, then giving up. After exhaustion, it logs "failed to reach opencode health". This bridge has been non-functional since 2025-02-05. This may also contribute to startup latency.

3. MCP config uses @latest — The default workspace config uses npx -y chrome-devtools-mcp@latest and npx -y n8n-mcp@latest, which checks npm for the latest version on every launch, adding unnecessary startup delay.

Suggested Fixes

1. Implement proper process lifecycle management — terminate openwork-server.exe when the associated window closes
2. Consider a singleton/shared server model to avoid redundant processes for the same workspace
3. Add cleanup logic on app startup to kill orphaned server processes from previous sessions
4. Pin MCP dependency versions instead of using @latest to reduce startup time