Built-in browser: add a user/policy preference to avoid repetitive per-origin website access prompts

Summary

The built-in browser asks for per-origin consent ("Allow website access?") before an agent can read a page, and the grant is scoped to one conversation and cleared on desktop restart. There is no user or admin setting to choose a more permissive default, so anyone doing repeated work on the same sites (for example their own analytics dashboards) has to re-approve the same origins over and over.

Current behavior

In electron/browser-task.mjs, access() (~line 197):

async function access(sessionId, tab, signal) {
  const url = browserTaskUrl(tab.view.webContents.getURL());
  const key = `${sessionId}:${url.origin}`;
  if (grants.has(key)) return;
  if (!isVisible(tab.tabId)) fail("needs_attention", "Select this tab in its conversation's browser panel to review website access, then retry.");
  publish(tab.tabId, "needs_attention", "Website access");
  const accepted = await confirm({ tabId: tab.tabId, title: "Allow website access?", message: `Allow this conversation to read ${url.origin}?`, approveLabel: "Allow reading this origin", detail: "For this conversation until desktop restart, it can read pages and site tool descriptions using the built-in browser's signed-in account. Website content is untrusted. Actions that change the page require separate approval.", signal });
  if (!accepted) fail("user_denied", "Website access was not allowed.");
  grants.set(key, true);
}

Two friction points:

• The grant key is ${sessionId}:${origin} and, by its own text, lasts "For this conversation until desktop restart" — so every new session and every app restart re-prompts for each origin.
• Approval also requires the tab to be visible and shows a modal confirm each time, so even within one session there is a manual step per new origin.

Why this matters

• Repetitive friction for legitimate repeated work on the same sites.
• No preference exists in the UI: Settings > Permissions covers authorized folders, browser login sync, and built-in browser sign-ins, but not website access consent.
• No desktop policy key covers it either. desktop-policies exposes Built-in Extensions allow/block (browser on or off) but not a consent preference.
• Teams end up patching the bundled app.asar by hand, which is fragile (app updates overwrite it) and effectively forks the app.

Proposal

Add a built-in browser website-access preference, ideally both user-settable and org-policy-controllable, with options such as:

• Ask for each origin (current behavior; safe default)
• Always allow this origin (persisted per-origin trust that survives restart)
• Auto-approve origins this conversation reads

Please keep the organization website allowlist enforcement (allowed(url) in resolve()) independent and always applied, so relaxing the consent prompt never bypasses org-level site blocking.

A persisted per-origin trust list, with a visible "revoke" control similar to the existing built-in browser sign-ins list, would remove most of the friction without eliminating consent entirely. A matching policy key (for example Browser website access) would let admins choose the default for a team.

Environment

• OpenWork desktop, organization-managed, Windows
• Reproduced while reading YouTube Studio analytics for the signed-in user's own channel; re-approval was required after desktop restart