🤖 perf: workspace-open git/PR executeBash calls compete with the cold-open replay

[ThomasK33]

Found while diagnosing #4624. Companion to #4661 (untrusted projects).

Problem

Even in a trusted project, opening a workspace competes with its own onChat replay:

• Server: the renderer fires four workspace.executeBash calls for the opened workspace ~5 ms before the replay starts (GitStatusStore status script, git fetch, PRStatusStore gh pr view, gh stack view). Their four bash spawns often land in the same tick. Each fork blocks the Electron main thread for ~11-16 ms, so there is ~55 ms of continuous event-loop lag inside the replay's history read. Cold-open historyReadMs for a 31 KB epoch is ~118 ms. When the main process is idle, the same read takes ~17-48 ms.
• Renderer: with the trusted fixture those calls finish sooner and their results render during the transcript paint. The cold-open gap from caught-up to first row grew from ~107 to ~139 ms, and dom.longestTaskMs from 87 to 146 ms (perf.chatSwitch, medians of 18 cold opens).

Trusted perf.chatSwitch medians after #4624's harness fix: cold-open-small server.totalMs 151.9, first row 388.3 ms (store switch).

Options

1. Start the workspace-open git/PR probes after the chat is caught up. Use the existing caught-up signal, not a timer, with a fallback when it never arrives.
2. Cut the eager calls on open: merge status and fetch into one script, and run gh stack view only when the PR is part of a stack.
3. Reduce the fork cost in the main process (a spawn helper), which also covers 🤖 perf: untrusted projects fork git 4× per executeBash from the main process #4661.

Measure with tests/e2e/scenarios/perf.chatSwitch.spec.ts (--workers 1, summarize with bun scripts/perf/chatSwitchTable.ts artifacts/perf/electron).

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[linear-code]

MUX-257

[ThomasK33]

Fixed by #4675 (merge commit 7881ab8). When a workspace opens, its git status, git fetch, gh pr view and gh stack view probes now wait until the chat replay reaches caught-up. If an onChat attempt ends without caught-up, or the workspace is deactivated or removed, the probes run anyway. No timers are involved. Cached git status and the persisted PR badge stay visible while the probes wait.

This took option 1 from the issue. Options 2 and 3 (fewer probes, a spawn helper) were not needed for this result. #4661 (untrusted projects) is still open and unchanged.

perf.chatSwitch (--workers 1), 4 alternating base/after runs on the same host, 12 switches per column per build. Medians in ms:

metric	cold-open-small	cold-open-large	switch-back-small	switch-back-large
renderer.firstRowMs (store switch)	246.9 → 153.1	286.5 → 216.2	25.9 → 28.4	27.1 → 25.3
renderer.caughtUpMs	183.8 → 86.3	173.7 → 114.3	75.3 → 67.3	220.6 → 182.0
caught-up → first row (difference of medians)	63.1 → 66.8	112.8 → 101.9	–	–
dom.firstRowFromClickMs	269.2 → 173.1	291.3 → 223.0	97.3 → 96.8	124.7 → 122.2
dom.longestTaskMs	69 → 75	104 → 107	98.5 → 98	127 → 129.5
server.totalMs	110.8 → 38.0	135.0 → 81.4	39.1 → 9.6	88.4 → 37.4
server.historyReadMs	87.6 → 28.1	94.2 → 50.1	26.7 → 3.1	41.2 → 24.8

• On cold open, the first row appears ~70-95 ms sooner, and the server replay is 2-3x faster.
• Switch-back did not regress.
• The renderer's longest task is flat. In these baseline runs the probe results did not land during the paint, so the 87 → 146 ms regression seen in 🤖 perf: cold-open onChat replay waits ~300 ms on main-process contention #4624 did not reproduce, and no longest-task improvement is claimed.
• Cost: git and PR status now start refreshing at caught-up, which is ~85-115 ms after the store switch on a cold open.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high