Clarify quit-sites dialog options and move auto-start to app.json

[bcotrim]

Related issues

• Fixes STU-1778

How AI was used in this PR

Used Claude Code to trace the quit / auto-start flow end to end, implement the new dialog, relocate the auto-start flag, and write the migration and tests. I reviewed the full diff, iterated on the dialog copy and button layout, and ran typecheck, lint, the unit suites, and manual verification.

Proposed Changes

When you quit Studio with running sites, the dialog used to offer a single Stop sites action — but it stopped the sites and then silently auto-restarted them on the next launch. So you'd ask to stop them, reopen Studio, and find them running again. Confusing enough that the team kept tripping over it (see the issue thread).

This replaces that one ambiguous action with three explicit choices, so what you pick is what you get:

• Leave running — sites keep running while Studio is closed.
• Auto-start — sites stop now and restart when you reopen Studio (the old "Stop sites" behavior).
• Stop — sites stop and stay stopped next time you open Studio.

It also moves the auto-start flag to where it conceptually belongs. Auto-start is a desktop-launch concern — only Studio's launch ever acts on it — yet it lived in CLI-owned config. It now lives in the desktop app's own storage, and the CLI no longer reads, writes, or accepts an auto-start flag. A one-time migration relocates the flag (and converts the old quit preference) for existing users, so nothing is lost on upgrade.

Known minor behavior change: starting a site from the CLI while Studio is closed no longer pre-flags it for auto-start (the site is running anyway, so nothing visible changes). Starting a site from the CLI while Studio is open is unaffected.

Testing Instructions

While Studio is closed, confirm site state with node apps/cli/dist/cli/main.mjs site list or by visiting the site URL — not the Studio UI, which auto-starts sites on reopen.

• Start two sites, then quit and try each option, reopening between runs:
  • Stop → offline while closed, stays stopped on reopen.
  • Auto-start → offline while closed, restarts on reopen.
  • Leave running → online while closed, still running on reopen.
  • Cancel → Studio stays open.
• Stop a single site by hand, then quit with Leave running → that site does not come back on reopen.
• Tick Don't ask again with a choice → the next quit skips the dialog and honors it.
• Create a new site, quit with Auto-start, reopen → it restarts.
• Upgrade path: an existing install with running-site auto-start keeps it after the migration, and the old quit preference is converted.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors? — npm run typecheck and eslint are clean; the CLI + Studio unit suites pass (incl. a new migration test).

[wpmobilebot]

📊 Performance Test Results

Comparing 9debe76 vs trunk

app-size

Metric	trunk	9debe76	Diff	Change
App Size (Mac)	2341.84 MB	2341.85 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	9debe76	Diff	Change
load	763 ms	1060 ms	+297 ms	🔴 38.9%

site-startup

Metric	trunk	9debe76	Diff	Change
siteCreation	6531 ms	6502 ms	29 ms	⚪ 0.0%
siteStartup	6987 ms	6492 ms	495 ms	🟢 -7.1%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[nightnei]

Tested different scenarios - it works like a charm ❤️
Briefly reviewed code, LGTM 👍 But would be good to have a review also from Fredrik, as he has better knowledge about this part of the codebase.

The copy also looks good, but I would propose a bit of an adjustment to somwthign like:

* Keep running — sites stay running after Studio closes.
* Auto-start — sites stop now and start again when you reopen Studio.
* Stop — sites stop now and stay stopped.

But up to you.

Thank Bernardo, for working and improving it ❤️

[bcotrim]

@fredrikekelund please let me know if you have any feedback on this one, happy to address it in a follow-up.

[fredrikekelund]

This is clearer for sure, but four buttons instead of three (plus the checkbox) is kind of a lot – especially considering how macOS changes the dialog appearance. I would call this dialog a bit overwhelming, tbh.

I also think "Auto-start" is a bit of a misleading button label. Users need to read the description to understand what it means, or they'll mistake it for something else if they read only the button label.

I would run this by @shaunandrews for input.

[shaunandrews]

ooofa, yea, this isn't great. Thanks for the ping. Not only is there a lot of options (the cognitive overhead is through the roof), but the order and placement of options makes is very hard to process and choose.

We need to simplify the copy and the layout. Instead of trying to explain every option in text, separate from their related button, we should present them in a better interface. A list of radio buttons is what comes to mind. I also think we'll need to make this a proper setting, so users can change it later.

I created STU-1908 to track iterations one this.