[FEATURE] Desktop: window appears in ~1s then sits blank for up to 117s with no progress indication (startup-perf already measures it)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

On macOS the Claude desktop app opens its window almost immediately — and then renders nothing at all for a long, unpredictable stretch. No spinner, no skeleton, no logo, no progress bar, no text. Just an empty window that looks exactly like a hung app.

The app already instruments this. Its own [startup-perf] log line records main_view_dom_ready_ms. Ten launches from my logs (~/Library/Logs/Claude/main*.log, all is_first_run: false):

| launch | window_created_ms | main_view_dom_ready_ms |
|---|---|---|
| 2026-07-16 23:24 | 1026 | 2334 |
| 2026-07-20 09:07 | 846 | 2494 |
| 2026-07-21 23:52 | 7705 | 44127 |
| 2026-07-21 23:54 | 559 | 116951 |
| 2026-07-22 09:02 | 1239 | 2377 |
| 2026-07-24 14:28 | 1044 | 1968 |
| 2026-07-30 17:02 | 722 | 1733 |
| 2026-08-03 15:14 | 1048 | 7640 |
| 2026-08-03 17:54 | 7658 | 9393 |
| 2026-08-04 18:50 | 1019 | 62575 |

Median ~7.6s, but 3 of 10 launches exceeded 10s and the worst was 117 seconds. In every one of those cases window_created_ms was ~0.5–1.0s — so the OS shows a real, focused, resizable window within a second, and that window then stays blank for up to two more minutes.

The 2026-08-04 launch has the richer breakdown, and it rules out the network as the cause:

window_created_ms:       1019
window_did_finish_load_ms: 1233
spa_ttfb_ms:              555     <- server answered in half a second
spa_dcl_ms:             61538     <- DOMContentLoaded 61s later
main_view_dom_ready_ms: 62575
spa_transfer_bytes:   3416389
spa_resource_count:        90

TTFB was 555ms. The remaining ~61 seconds is client-side work between first byte and DOMContentLoaded, during which the user is shown a blank window and told nothing.

The behavioural cost is a restart loop, and the restart makes it worse. Look at the two 2026-07-21 rows: a 44-second blank window, then a new launch 2 minutes 21 seconds later that took 117 seconds. That is the signature of a user concluding the app was hung, force-quitting, relaunching into a colder cache, and waiting nearly twice as long. I have done this repeatedly, and each time I am guessing whether the app is loading or dead — there is no information on screen that distinguishes the two.

This is not a "make startup faster" request. Startup time can stay exactly as it is. The gap is that a window is presented as ready when it is not, and the app withholds state it is already computing.

Proposed Solution

Do not show an empty window. Between window_created and main_view_dom_ready, render something — in rough order of value:

1. A minimal native splash/loading state painted by the main process, before the SPA takes over. Anything at all — the Claude logo plus a spinner — converts "this app is frozen" into "this app is working." This alone would have prevented every restart I have made.

1. Escalating copy once the wait becomes abnormal. The app knows what normal looks like; it is logging it. After ~10s: "Still loading…". After ~30s: "Loading is taking longer than usual — restarting will not speed this up." That second sentence is the whole feature. It is the single thing that would have stopped the 07-21 restart that cost 117 seconds.

1. Say what it is doing, if the phase is known — restoring sessions, syncing skills, loading plugins. My last launch restored 92 persisted sessions and 50 navigation-history entries; naming that would make a long wait legible rather than alarming.

1. Optionally defer the window itself. Hold the window until main_view_dom_ready, showing only the Dock bounce. Less good than a splash (the app then looks like it did not launch), but strictly better than a blank window that looks crashed.

1. Surface startup-perf to the user — an About-panel line, or a one-time toast after an unusually slow start. The measurement exists; it is currently visible only to whoever reads the log file.

Alternative Solutions

• Just make startup faster. Worth doing separately, but it does not solve this: any variance leaves some launches slow, and a blank window is uninformative at 8 seconds too. The feedback gap is independent of the duration.
• Document it ("startup can take a while"). Nobody reads release notes at the moment their app appears frozen.
• Ship the progress UI only for launches predicted to be slow. Adds a prediction problem to a problem that does not need one — the cheap version always shows the splash and simply escalates its copy over time.

Priority

Medium - Would be very helpful

Feature Category

Performance and speed

Use Case Example

I restart the desktop app fairly often — after an update, after a hang, when switching what I am working on.

What happens today: I quit, relaunch, a window appears in about a second, and then I stare at a blank rectangle. At ten seconds I wonder if it is stuck. At thirty I am fairly sure. At sixty I force-quit and relaunch — which lands me in a colder start and a longer wait. My logs caught this exactly once in the raw: 44s blank → restart → 117s blank.

What I want instead: a window that shows a logo and a spinner immediately, and after roughly thirty seconds tells me plainly that it is taking longer than usual and that restarting will not help. I would then simply wait, and the 117-second launch would never have happened.

For scale, this install is not tiny — 92 persisted sessions, 64 project histories, ~1.5 GB of session transcripts, 8.7 GB of app support data. If load time scales with any of that, heavy users hit the slow tail most often, which is precisely the group most likely to have unsaved context riding on the restart.

Additional Context

Environment

• macOS 26.6, Apple Silicon (arm64)
• Claude Desktop 1.25927.0 (also seen on 1.24012.9 and 1.24012.11)
• Claude Code 2.1.221
• Electron / Node 24.18.0
• Not first run in any measured launch (is_first_run: false throughout)

Where the data comes from: ~/Library/Logs/Claude/main*.log, one [startup-perf] block per launch. Reproducible on any install:

grep -A14 "startup-perf" ~/Library/Logs/Claude/main*.log

Duplicate search. I looked for this across several phrasings and found nothing covering it. The nearby issues are different failures: #62245 / #62242 (Windows, hangs permanently), #68364 (Windows MSIX, title-bar overlay crash), #47082 / #52043 (macOS, never renders at all), #26292 (infinite spinner from an unhandled OAuth 403 — and notably that one at least shows a spinner). All of those are launches that never succeed. This one succeeds every time; it just does so silently, sometimes two minutes later.

Why I think this is cheap to fix: the measurement, the phase boundaries, and the "is this slower than usual" signal all already exist in the code that writes startup-perf. What is missing is a paint between window_created and main_view_dom_ready.

Thank you for the app — the desktop client is where nearly all of my work happens, and this is the one place it leaves me guessing.