Desktop account bootstrap is blocked when Chrome trusted RPC fails and device auth is killed at 120 seconds

The use case

A user wants to bootstrap a narrow, service-only Microsoft 365 mailbox integration from the Codex desktop app on Windows:

• one Microsoft 365 mailbox only
• no browser/UI automation after setup
• certificate-backed service identity
• Exchange Application RBAC restricted to that mailbox
• user performs the normal one-time administrator authentication

This is ordinary authorized account setup, not credential scraping or unattended browser use.

Failure 1: Chrome bridge fails before browser access

The Chrome-extension route consistently fails during runtime setup with:

Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/sscaz/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

The error occurs before a Chrome tab is enumerated or interacted with. Reinstalling the Chrome extension and restarting Codex did not resolve it.

Failure 2: the reasonable fallback cannot complete

The fallback used Microsoft device-code authentication. It correctly displayed a code and waited for administrator authorization, but the Codex command session killed the authentication after 120 seconds:

Authentication timed out after 120 seconds due to inactivity. Please try again.

The user completed the Microsoft sign-in twice; the local Codex watchdog ended the process before the callback was received. Launching an external terminal avoids the watchdog but destroys the agent-managed, verifiable flow and leaves the user holding the bag.

Why this matters

Codex can currently perform the architecture, code, preflight, and security scoping, but cannot reliably complete a legitimate one-time OAuth/bootstrap handoff when its browser bridge is broken. That makes it unable to deliver end-to-end setup for a very common class of integrations.

Requested product behavior

1. Fix the desktop Chrome trusted-RPC path so extension-backed Chrome control can initialize reliably on Windows.
2. Do not apply a short inactivity timeout to a foreground OAuth/device-code command awaiting explicit user authorization; allow a bounded but human-realistic window (for example 10 minutes), with clear cancellation.
3. Surface the actual browser/runtime failure in the desktop UI, along with a supported recovery path.
4. Preserve a secure, user-approved, agent-verifiable bootstrap route for account integrations—without falling back to credential handling or browser-state extraction.

No Microsoft 365 application, mailbox scope, scheduled job, or automated mail behavior was created during this failed attempt.