fix(web): preserve explicit preview navigation URLs - #8902

💭 I want to look at the actual file to understand this change—the PR removes the localhost-to-remote mapping for explicit URL navigation in the browser target resolver, and also drops the check that threw for authenticated preview gateways. This seems related to environment routing in shared renderers, so I should inspect the file directly to confirm.

1. browse_code — apps/web/src/browser/browserTargetResolver.ts

2. browse_code — apps/web/src/browser/browserTargetResolver.test.ts

💭 This is more of a functional navigation change than a UI consistency issue, though the environment routing section might still apply. I'm tracing who calls resolveBrowserNavigationTarget with the "url" kind to see if reverting the localhost-to-remote mapping breaks anything downstream. The original mapping seemed intentional—since the preview browser is an Electron webview on the local machine, localhost normally points there, but the remote environment case needed that redirect to reach the dev server. I want to check the git history and issue #8885 for context on why this mapping existed before searching for the actual callers.

3. git_tools — resolveBrowserNavigationTarget|resolveDiscoveredServerUrl

4. git_tools — apps/web/src/browser/browserTargetResolver.ts

💭 I want to trace the history here—checking the commit that this PR reverts, plus an earlier related commit, since there seems to be a flip-flop in how localhost preview URLs were handled. I should also check the linked issue and PR description, and look at the specific lines in PreviewAutomationHosts.tsx that handle URL navigation.

5. github_api_read_only — repos/{owner}/{repo}/pulls/{pull_number}

6. browse_code — apps/web/src/components/preview/PreviewAutomationHosts.tsx

💭 I need to figure out whether the preview browser navigates on the client machine or the remote environment server, since that determines whether localhost needs rewriting to point to the environment host. Let me check issue #8885 for details on the original bug report.

7. github_api_read_only — repos/{owner}/{repo}/issues/8885

8. git_tools — bde0a4c

💭 For the UI Consistency check, this doesn't seem to fall under the listed rules like environment routing in shared renderers. Though I'm noticing a possible regression: resolveDiscoveredServerUrl now always maps loopback hostnames to the environment host, whereas before it preserved the normalized URL when the environment was local loopback. Tracing through resolveEnvironmentPortTarget confirms the local loopback case still normalizes to "localhost" as before, matching the existing tests, and the public relay environment case still throws and falls back to rawUrl exactly as it did previously — so both paths preserve prior behavior. Now I'm checking whether the address bar's typed-URL path in PreviewView, which also calls resolveDiscoveredServerUrl, might introduce a regression since that path used to go through resolveBrowserNavigationTarget too, so it likely behaves the same, but I want to verify by looking at how PreviewView actually uses that resolved value.

9. browse_code — apps/web/src/components/preview/PreviewView.tsx

10. browse_code — apps/web/src/components/preview/useDiscoveredLocalServers.ts

💭 The discovered-server behavior stays the same, and typed URLs already skip resolution, so preserving explicit MCP URLs matches the earlier precedent from #3938. I'm now checking for potential regressions, specifically around how 0.0.0.0 hostnames were previously rewritten even in local environments, since Chromium can't actually navigate to that address. Actually, this is a real regression: explicit URLs like "0.0.0.0:5173" used to get normalized to a reachable host, but now they pass through unchanged and will fail to navigate on macOS/Windows since 0.0.0.0 isn't reliably navigable in Chrome. That said, I'm questioning whether this counts as a "UI consistency" issue given the check's rules focus on component systems, Tailwind, CSS, and environment routing in shared renderers, and this file is a resolver rather than UI code. Given the check's scope is UI consistency and the diff touches no UI components or styling, I don't see any findings under this check's rulebook even though the 0.0.0.0 regression is a real functional concern outside its scope. Since there's a conflict between instructions telling me to respond with exactly "All clear" versus the requirement to output valid JSON matching a schema, I'll resolve this by treating "no findings" as the outcome and structuring my response accordingly within the JSON format. Before finalizing, though, I want to check whether resolutionKind values like "direct-private-network" drive any user-facing labels or badges in the UI, since the rule requires capability gating, action dispatch, and labels to read from the same environment's config consistently. I should search for where resolutionKind is consumed to verify nothing breaks.

11. git_tools — resolutionKind|direct-private-network

💭 Since there are no UI consumers here, there's nothing to flag for UI consistency, so I'll respond with an "all clear" success state.