This has come up before with Safari on iOS specifically — it's usually a MIME type issue where Safari decides to download the response instead of rendering it when something in the headers looks off. The most likely culprits are a missing or incorrect Content-Type header on the response, or Safari receiving a response it interprets as a file download trigger like Content-Disposition: attachment coming from somewhere in the Codespaces proxy layer rather than your app itself.

Since the workspace is gone the most useful thing to capture next time it happens is the full response headers from Safari — you can get these by connecting the iPhone to a Mac and using Safari's Web Inspector to inspect the network request that triggered the download. That'll tell you immediately whether the download header is coming from your app or being injected somewhere between Codespaces and the client.

Also worth noting the exact iOS and Safari version when it happens since this kind of behaviour has shown up in specific Safari releases around how it handles authenticated proxied responses. If you can reproduce it in a fresh Codespace, capturing a HAR file from Web Inspector at the moment it downloads instead of renders would be the most useful diagnostic to attach to a support ticket.

1. Record the full environment: iOS version, Safari version (or Chrome/Firefox on iOS, which also use WebKit), and whether Private Browsing or "Prevent Cross-Site Tracking" was on. Private ports rely on a GitHub sign-in redirect and cookies on a different domain, so cookie blocking can change what Safari receives.

2. Compare the same URL in other clients at the same moment: desktop browser, another phone, and curl with your GitHub token (see the Codespaces docs section "Using curl to access a forwarded port"). Check Content-Type, Content-Disposition, and X-Content-Type-Options in the headers. If curl is fine but Safari downloads, the difference is on the browser or auth side.

3. Capture Safari's real response: use Web Inspector from a Mac (Settings → Safari → Advanced → Web Inspector on the iPhone). If you don't have a Mac, a debugging proxy such as mitmproxy or Charles on the phone's Wi-Fi works too. Save a HAR and look at the final authenticated
   response after the redirects, not just the first one.

4. Isolate the proxy layer: in a disposable codespace with non-sensitive content, temporarily switch the port to Public and test on the same iPhone. If it renders, the issue is in the private-port auth flow rather than your app.

5. Make your app explicit: set Content-Type: text/html; charset=utf-8 in the Node.js response yourself, so a missing type can be ruled out.

This sounds like it could be related to Safari handling the authenticated Codespaces response rather than the Node.js app itself. If it happens again, I’d capture the exact iOS/Safari version, response headers, content type, redirects, and whether the issue also occurs with another browser or a public port. That should help determine whether it’s a Safari or Codespaces-specific issue.