🤖 perf: workspace.activity.list ships 13,895 stale entries (2.9 MB, ~59 s) — extensionMetadata.json never prunes

[ThomasK33]

Summary

Separable live anomaly found during the WS-traffic investigation (see the main issue): on a long-lived deployment, ~/.mux/extensionMetadata.json contains 13,895 workspace entries while only 246 workspaces are live (1,513 in config including archived). Entries for removed workspaces/sub-agents are never pruned.

Impact (measured live)

• workspace.activity.list returns 13,901 entries = 2.89 MB of uncompressed JSON on every client boot/reconnect (the sidebar needs ~246).
• The call took the server ~59 s to answer: getActivityList() (src/node/services/workspaceService.ts:12521-12599) unions extensionMetadata.getAllSnapshots() keys and then bootstraps getActiveWorkflowRunIds(workspaceId) — a per-workspace disk probe — for all 13,901 ids (workspaceService.ts:12551, 3737-3762).
• That response shares the single ordered /orpc/ws socket with the boot-gate-critical responses, contributing directly to the minutes-long "Loading Xum" lockout.

Suggested fix

• Intersect getActivityList() ids with config-known (live) workspaces instead of every snapshot key on disk, keeping the workflow/bash-monitor tombstone semantics for known workspaces.
• Prune extensionMetadata.json entries when workspaces are removed (plus a one-time lazy cleanup at load for pre-existing deployments). Keep the on-disk file backward-compatible (filter at read) per upgrade↔downgrade policy.

A healthy/fresh deployment does not exhibit this: activity.list is a few KB and instant. This is a state leak that grows monotonically with deployment age.

Related: #MAIN_ISSUE

---

Generated with xum • Model: anthropic:claude-fable-5 • Thinking: xhigh • Cost: $1.01

[linear-code]

MUX-121

[ThomasK33]

Main investigation issue: #3960