[app/browser] Auth fallback can switch browser profiles without an identity confirmation gate

Installed versions

• Codex Desktop app: 26.810.41047, bundle 6570, macOS arm64
• Bundled Browser and Chrome plugins: 26.810.41047

Reproduction

Both installed browser skills say at line 157 that when the user did not explicitly choose a browser and the runtime-selected browser lacks authentication, Codex should select another available browser before asking the user to sign in.

The selected-browser documentation exposed to the skill reports the browser name, type, and ID, but the documented flow does not require comparing a browser profile marker or a visible account identity before continuing in the replacement browser.

This is especially inconsistent in the Chrome package: its plugin description says missing or expired authentication should prompt reauthentication or require explicit approval to use Chrome as a fallback, while the shared skill permits automatic fallback when the initial browser was runtime-selected.

No account, cookies, tabs, or authenticated site content were accessed for this report; the contradiction is present in the packaged contracts.

Expected behavior

Before changing authenticated browser surfaces, Codex should either:

1. Obtain explicit user approval for the fallback, or
2. Verify a non-sensitive profile marker and visible target account identity and stop on unknown or mismatched identity.

Actual behavior

The normative flow can move from an unauthenticated surface to another available browser and continue without an explicit account/profile identity gate.

Proposed narrow fix

Require explicit fallback approval whenever authentication drives a browser change. If automatic selection remains supported, require a profile marker plus visible site-account verification before any authenticated read or action; fail closed when identity is unknown or mismatched.

Acceptance test

Use fixture browser inventories with two profiles:

• Unknown identity: fallback is blocked.
• Mismatched visible account: fallback is blocked.
• User explicitly approves a named fallback and the visible account matches: fallback is allowed.
• Explicitly selected browser: no automatic switching occurs.

The test must not require real account credentials or cookies.

This report does not request editing the managed cache; the fix belongs in the upstream bundle source.

Start at line 157 of the shared browser skill and compare its fallback contract with the Chrome plugin description about reauthentication and explicit approval. Trace these packaged contracts to their upstream bundle source, then run the fixture browser-inventory acceptance tests. Done means unknown or mismatched identities block fallback, explicit approval with a matching account permits it, and explicitly selected browsers never switch automatically.