Agentic UI: Recover the site preview from cached cross-site redirects

[bcotrim]

Related issues

• Fixes STU-2217

How AI was used in this PR

Claude Code traced the root cause and wrote the change. Diagnosis was driven by a deterministic repro (below) rather than inspection — three plausible causes were ruled out by experiment first.
Manually validated the fix and reviewed the code

Proposed Changes

Site ports are recycled between sites, and every preview shares one persistent webview session. So a permanent redirect cached while a port belonged to one site later hijacks whichever site inherits that port: the frontend tab renders someone else's site while wp-admin and phpMyAdmin look correct.

Users had no way out. Restarting the site, the reload button, switching sites, and restarting the app all fail — Chrome keeps cached 301s through every reload variant, and the redirect leaves the webview parked on the other site's URL, so reloading just reloads that.

The preview now notices when a load it started settles on a different origin and recovers itself, so this heals without the user knowing a cache exists. A Hard refresh item in the ⋮ menu (⌘⇧R) does the same on demand, covering stale caching we can't detect automatically — same-origin cached redirects, stale theme assets. Only the HTTP cache is dropped, so preview logins survive.

Testing Instructions

1. Create two sites and note their ports (below: A on 8931, B on 8932).
2. Give B a wp-content/mu-plugins/redirect.php that 301s the front end to A:

   <?php
   add_action( 'template_redirect', function () {
       wp_redirect( 'http://localhost:8931/', 301 );
       exit;
   } );

3. Open B's preview — it shows A.
4. Delete the mu-plugin. Confirm the server is clean: curl -sI http://localhost:8932/ returns 200 with no Location.
5. Switch to A and back to B. B recovers on its own (before this PR it stayed on A permanently).
6. Check ⋮ → Hard refresh and ⌘⇧R, with focus both inside the preview and in its chrome.
7. Confirm wp-admin still auto-logs in — the cache clear must not drop cookies.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing d0b3eeb vs trunk

app-size

Metric	trunk	d0b3eeb	Diff	Change
App Size (Mac)	1406.29 MB	1406.29 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	d0b3eeb	Diff	Change
load	1062 ms	1034 ms	28 ms	⚪ 0.0%

site-startup

Metric	trunk	d0b3eeb	Diff	Change
siteCreation	7495 ms	7592 ms	+97 ms	🔴 1.3%
siteStartup	2868 ms	2870 ms	+2 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

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

[sejas]

@bcotrim, what do you think about simplifying the logic and always performing a hard refresh? I didn’t notice any slowness when triggering a hard refresh on my test sites, probably because they’re local and network latency is negligible.

I tested the app, and confirmed there is a new button to produce the hard refresh and it solves the redirection issue. Thanks!

[bcotrim]

@bcotrim, what do you think about simplifying the logic and always performing a hard refresh? I didn’t notice any slowness when triggering a hard refresh on my test sites, probably because they’re local and network latency is negligible.

Do you mean removing the origin check? I think it's a cheap validation that prevents unnecessary hard reloads, if we do it every time, it means loading —> clear cache —> reload always. Locally it's probably ok, but it's unnecessary.
If this was not what you mean let me know, I'm merging this one to try and include in the release, but happy to do follow-up with your suggestion.

Thanks for the review! 🙇

[sejas]

All good. Thanks for merging it. It was just a thought that maybe the regular refresh button could clear the cash in all cases, so we wouldn't need a hard refresh option there, and users could easily hard refresh even without knowing. We can reconsider that option in the future based on user feedback. It could also help with some cached CSS and JS when developing a site.