Feature request: let users explicitly select the Chrome profile/window Codex should control

Summary

When multiple Chrome profiles/windows are open, Codex Browser/Computer Use can have difficulty attaching to the intended existing Chrome session. For production-sensitive workflows, users need a deterministic way to tell Codex exactly which Chrome profile/window/tab to control instead of relying on automatic discovery.

Problem

The official ChatGPT/Codex Chrome extension is installed and enabled, and ChatGPT Desktop shows Google Chrome under Computer use. However, when several Chrome profiles or windows exist, the user has no obvious UI to say:

• use this Chrome profile,
• use this signed-in Chrome account/session,
• use this window,
• and preferably use this currently active tab.

This can cause Browser/Computer Use tasks to fail to attach to the intended session or to require manual troubleshooting at a sensitive action-time gate.

This is especially problematic for production workflows where silently falling back to a different profile/browser is unsafe.

Requested UX

Please add an explicit browser-target selector for Chrome Computer Use / Browser Use.

Possible UI:

1. Settings → Computer use → Google Chrome

   • show detected Chrome profiles/instances,
   • show the user-visible Chrome profile name,
   • show a stable profile directory/ID,
   • optionally show a privacy-preserving signed-in account identifier for disambiguation,
   • show whether the OpenAI extension/native bridge is connected.

2. Per-task / per-thread target picker

   • choose a specific Chrome profile,
   • choose a specific Chrome window,
   • optionally choose the current active tab,
   • allow pinning that selection to the current Codex thread/project.

3. Visible confirmation before sensitive actions

   • show which Chrome profile/window Codex is currently attached to,
   • never silently fall back to another Chrome profile/browser if the selected target is unavailable,
   • fail with an actionable message such as Selected Chrome profile is not attached.

Suggested agent/runtime support

Expose profile/window metadata through the Chrome backend so Codex can deterministically select a user-approved target, for example:

• stable profile ID/directory,
• profile display name,
• browser process/window ID,
• active tab ID/title/origin,
• connection/extension health.

The user should be able to select by profile display name, stable profile ID, or another explicit identifier. A signed-in account label could be shown only as a local/user-visible disambiguator rather than being unnecessarily sent to the model.

Safety benefit

This is not only a convenience feature. Deterministic Chrome-profile selection would reduce the risk of Codex acting in the wrong signed-in account or production environment. For high-risk tasks, the correct behavior should be no silent substitution.

Environment

• macOS
• ChatGPT/Codex Desktop
• official ChatGPT Chrome extension
• multiple Chrome profiles/windows

Related

Related to #22251, which asks for deterministic selection when multiple extension-backed Chromium targets are connected. This request focuses specifically on a first-class user-facing Chrome profile/window selector for normal Chrome workflows.

No files or tests are identified in the issue. Start by reviewing the Chrome backend and related issue #22251 to understand existing target discovery, then define the profile/window selection flow and its safety rules. Done means users can select and confirm a target, with no silent substitution when it is unavailable.