Repository navigation
macOS built-in Browser blocks PropFinder despite explicit Browsing: Always allow #47131
Description
Activity
Strong reproduction because the visible origin setting and the runtime decision disagree. I would model the check as an explainable policy-resolution result rather than a single origin bit: record the canonicalized origin match, scope, policy source, decision, policy generation or version, and precedence in a values-free diagnostic receipt.
The error should distinguish at least: an explicit user deny, a matching saved allow that is stale or not loaded, a task or host policy, an account or session security gate, and an unsupported browser surface. It should not say a saved user block caused the rejection unless the resolver found the matching deny entry. If an allow is present but another layer wins, name that layer and provide the supported recovery path.
A regression matrix could cover exact origin normalization, ports and redirects, subdomain boundaries, an already-open authenticated tab versus a new navigation, explicit tab mention versus discovery, task restart, scheduled-task context and policy reload. Keep the receipt free of page content, cookies and identifiers. I maintain Hronaut, a local visible Browser/MCP workspace, and use the same discovery-versus-authority/read-back boundary in evaluator notes. I have not run Codex on this issue, so I am not claiming a result. AI-assisted note.
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Summary
On macOS, Codex's built-in Browser refuses to inspect an open, authenticated
https://propfinder.app/nfltab even though Settings → Browser → Agent permissions shows Browsing: Always allow forhttps://propfinder.app(and for Default). The user can open the site manually. This blocks a read-only, scheduled research workflow.Steps and observed behavior
https://propfinder.app→ Browsing to Always allow in Agent permissions. The visible default is also Always allow.The permission mismatch persisted across retries after the user confirmed the setting. A read-only check of local Codex configuration also showed
[browser_use.origins."https://propfinder.app"] access = "allow"; it did not establish why Browser Use applies a denial. The same site was accessible to Codex in a different task on September 19, 2026. During a scheduled task on September 20, the first opening attempt was declined; subsequent attempts in this task report a saved block. This chronology does not prove a cause.Expected
The explicit origin-level allowance permits the authorized read-only browser operation, or the UI identifies an overriding policy and provides a supported way to recover. It should not attribute the rejection to a saved user block that contradicts the visible setting.
Impact and privacy
The scheduled task cannot produce its requested output from the authenticated site. No account details, credentials, session identifiers, screenshots, site data, or full logs are included here. No alternate browser surface or policy workaround was used.
Potentially related symptom: #43754 and #44895.