Add secure 1Password support to the Codex integrated browser

Open 💬 2 comments Opened Jul 10, 2026 by velisnolis

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex App for macOS

What feature would you like to see?

Add secure 1Password support to Codex's integrated browser so users can authenticate without copying credentials into prompts or switching browsers.

Ideally, Codex should support one or both of these approaches:

Compatibility with the official 1Password browser extension.
A native integration with the 1Password macOS app, using the standard user-approved autofill flow.

The integration should preserve 1Password's security model: Codex should not receive or expose plaintext credentials unless the user explicitly approves an autofill action. It should also support passkeys and one-time passwords when available.

Additional information

This would make authenticated browser workflows safer and smoother, especially for development, QA, and administration tasks. Today, users may need to switch to an external browser or manually copy credentials, which adds friction and increases the risk of accidental secret exposure.

Related broader request: #19276 (authentication and sign-in support in the in-app browser). This request is specifically about secure password-manager integration and 1Password support.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#31204

Powered by Codex Action

BaseInfinity · 19 days ago

Windows integrated-browser reproduction supporting a platform-neutral, user-approved autofill design:

Platform: Windows 10 22H2, build 19045, 64-bit.
Bundled Browser plugin generation: 26.803.41515.
The user had already saved the username in the browser password manager and explicitly authorized sign-in.
When the Microsoft sign-in page appeared, a manual Next/account interaction caused the saved browser state to autofill and the authenticated session then worked normally.
Codex could continue after the user action, but could not invoke the saved autofill/account choice itself even though no plaintext credential needed to enter model context.
Repeated manual handoffs materially interrupt long-running Copilot Studio and Power Platform E2E automation.

The requested behavior is not access to plaintext passwords or autonomous MFA/consent. A safe implementation could:

Let the user approve an autofill request for the current origin and named saved login.
Ask the browser/password manager to fill locally without exposing the value to the model, DOM snapshots, logs, or tool results.
Record only that an approved credential alias was used successfully or failed.
Stop for password-manager unlock, MFA/OTP, passkey/biometric confirmation, consent, or any account mismatch.
Resume the same browser task automatically after the user completes one required secure prompt.
Treat already-signed-in account-tile selection as the narrower permission proposed in #37512.
Use the alias-based local secret boundary proposed in #22029 for non-browser child processes.

This is the same underlying need as the 1Password request, but reproduced on Windows with Microsoft/Power Platform sign-in and the browser's saved credential state. No account, tenant, credential, URL, or repository identifier is included.