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.

No repository files, tests, or code entry points are identified. Start by locating the Windows desktop trusted-RPC setup around browser-service.mjs and the 120-second device-auth watchdog; done means both recovery paths support a user-approved bootstrap without premature termination and surface actionable errors.