Avoid unsolicited local network prompt in bb connect

[ymichael]

Summary

• stop remote bb pages from probing the browser-local host daemon before loopback access is granted
• add an explicit Settings → Files opt-in for local editor integration
• support both the current loopback-network permission and the legacy local-network-access name
• preserve automatic local helper discovery for localhost and the desktop app
• document the updated multi-device workflow

Context

Chrome now gates requests from public origins to loopback addresses behind Local Network Access permission. The existing automatic host-daemon status probe therefore showed a browser permission prompt during ordinary bb connect page loads.

This change queries the existing permission state without triggering it and fails closed for remote web origins. The fetch that can prompt is kept directly in the Enable button click handler, so permission is requested only after an explicit user action.

Testing

• pnpm exec turbo run test --filter=@bb/app --force — 344 files, 2,725 tests passed
• pnpm exec turbo run typecheck --filter=@bb/app
• pnpm exec turbo run build --filter=@bb/app
• pnpm exec turbo run lint --filter=@bb/app — zero errors
• live Chrome QA through a bb connect URL with permission state prompt: zero loopback requests and no LocalNetworkAccessPermissionDenied failures during page load

AGENT GENERATED: by GPT-5 Codex

[bb-slop-cop]

🚨 SLOP COP 🚨 · review

I am SlopCop. I am reviewing this change now.

I will check security, code quality, architecture, performance, and the complete user flow.

[bb-slop-cop]

🚨 SLOP COP 🚨 · review

Plain-English summary

This change stops remote bb pages from contacting the local helper during normal page loads. It adds an Enable action under Settings → Files.

Desktop pages and local pages keep automatic editor discovery. The main design is sound, but three user paths need fixes.

Findings

1. High: A successful Enable request does not persist when the browser cannot query either permission name.

   The direct request can reach the helper. The refresh then returns to unsupported, hides the port, and stops editor discovery.

   Store the successful request as session access. Add a test with no supported permission query and a valid helper response.

2. Medium: The new loopback check excludes *.localhost and most of the 127.0.0.0/8 range.

   This repository uses bb.localhost and its subdomains for local Connect tests. The browser check showed the wrong opt-in flow on pr1608.localhost.

   Three frontend loopback classifiers now disagree. Move the browser-safe rules to one shared helper.

3. Medium: Users cannot retry after they start an unavailable helper.

   The UI tells users to start bb locally, but it disables the button and does not poll again. The helper can remain unavailable until reload.

   Keep an active Retry action. A short bounded poll or a clear reload instruction can also solve this case.

Security and performance

The new gate prevents an unsolicited loopback request before a user action. I found no new security defect in that gate.

The two settings consumers share one Jotai atom. I found no permission-query loop on each render.

A successful Enable request discards its status result. This causes one duplicate status request and makes the first finding harder to fix cleanly.

Checks

• All 344 app test files passed, with 2,725 tests.
• The @bb/app Turbo type check passed.
• The four focused test files passed, with 24 tests.
• git diff --check passed.
• All reported GitHub checks passed.
• Chromium 145 showed local editor choices on the localhost route.
• The pr1608.localhost route sent no helper request before Enable.
• A simulated unsupported Permissions API returned to Enable after a successful explicit request.
• The helper rejected the test remote origin because it lacked a client mapping.
• That restriction prevented a complete authorized remote-origin success test.

Chrome 145 uses loopback-network and keeps local-network-access as an alias, so the permission-name order is correct: https://developer.chrome.com/release-notes/145

I would fix the first two findings before merge. I posted this as a comment review only.