Codex Desktop: declared owner-auth and secret-manager capabilities are absent at runtime

Reporter clarification / blocking user impact:

The user specifically asks that the credential refusal itself be treated as part of the report.

This is not a request to expose passwords to the model or weaken account security. The blocking product problem is that Codex refuses a password supplied in chat (which may be an intentional security boundary) while the same session provides no supported alternative way for the owner to supply or authorize that credential:

• no Google Password Manager bridge;
• no callable Google Secret Manager opaque-reference consumer;
• no owner-only secure password-entry surface attached to the active browser;
• no live owner_assistance_* tools despite the skill declaring them;
• no documented supported handoff that keeps the value outside model context.

As a result, the user is told to provide credentials securely but is given no usable channel to do so, and the external workflow deadlocks after repeated login-window expirations.

Please document and implement the exact supported mechanism by which an owner can provide a website credential to Codex without placing it in chat. A suitable design could be an owner-only UI or an opaque secret reference consumed host-locally and session-bound, with no secret value exposed to the model, logs, or tool arguments. The capability must be preflighted before the browser window opens.

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

• #36932

Powered by Codex Action

Additional investigation and scope clarification:

I reviewed the automatically suggested duplicate, #36932. There is overlap around tools being declared/installed but absent from the live Codex surface. However, #37695 is not only a tool-mounting issue. Even if all declared MCP tools were mounted correctly, Codex still has no documented, supported owner-only credential handoff for a third-party website.

I also evaluated whether changing the model/provider would avoid this deadlock:

• Google's official Gemini 3.6 Flash Computer Use requires a client-side executor and returns safety decisions that can require user confirmation. Google explicitly warns against unsupervised use for sensitive data, critical decisions, or actions that cannot be corrected, and treats government-record modification as a protected category.
• Moonshot's Kimi K3 supports tool calls, but the host application still executes those calls. No verified built-in Google Password Manager / Google Secret Manager bridge was found there either, and its official terms caution against relying on model output for legally significant decisions.

So this is a provider-agnostic integration gap, not something solved by switching from Codex to another model. A safe architecture still needs:

1. an owner-only secure input surface or opaque secret reference;
2. host-local, in-memory consumption bound to one approved origin, browser session, and field;
3. no secret value in model context, screenshots, chat, logs, tool arguments, or persisted transcripts;
4. explicit owner confirmation for CAPTCHA, legal consent, and final submission;
5. deterministic preflight before browser launch, and an auditable boolean-only receipt.

The Help Center assistant accepted the account contact and stated that there is currently no built-in third-party website secret-handoff mechanism, but no human ticket/reference was issued. A follow-up email has now been sent to OpenAI Support requesting human review and a ticket reference.

No credentials, account identifiers, external case details, screenshots, cookies, or session data are included in this update.

Support status update: OpenAI Support has now issued a case reference and confirmed that the report was escalated to a support specialist, with a response expected in the coming days. The private support reference is intentionally not posted here. The public technical tracking remains this issue (#37695).

Correction to the reporter record and a narrower product request:

The observed prohibition on using a password pasted into the conversation was enforced by our local Multi Server Sync owner-operations-policy. It was not established as an OpenAI Codex product policy. Please disregard any reading of my earlier clarification that Codex itself categorically rejects credentials supplied in chat.

The Codex product gap is narrower and independently reproducible: Codex 0.147.0 documents keyring storage for Codex/MCP OAuth credentials, environment-variable forwarding, and command-backed authentication for model providers, but I could not find a supported generic, one-time secret-ingress surface for an arbitrary authenticated local tool or third-party website. There is no documented way for an owner to choose an OS password-manager item or enter a value into a protected prompt and give the agent only an opaque, expiring handle bound to one origin/executable/tool call.

Without that primitive, a security-conscious deployment has to build and maintain an external broker, such as a custom MCP/GSM integration. That adds cloud-secret-manager cost, IAM/network setup, plugin/runtime maintenance, and availability dependencies. If the broker is unavailable or not mounted in the active session, the only remaining safe path is repeated human login handoff, which interrupts long-running automation and causes short login windows to expire.

Minimal secret-free reproduction:

1. Start a local Codex task that must authenticate an approved child process or third-party website.
2. Pre-authorize use of a fictitious secret alias such as TEST_LOGIN_PASSWORD; do not place any value in the prompt or repository.
3. Attempt to select that alias from the OS password manager or supply it through a protected, one-time Codex input.
4. Observe that no generic built-in handle is available. The operator must provision a custom external broker/environment integration or manually take over authentication.

Requested product primitive:

• a protected local input/picker for session-only secrets and OS password-manager items;
• an opaque handle visible to the model, with the value resolved only in the trusted local runtime;
• binding to one workspace, origin or executable, field/tool call, and expiry;
• explicit approval for first use and scope expansion;
• injection via environment, stdin, temporary file, HTTP header, or browser autofill without command-line/model-context exposure;
• value redaction from transcripts, shell snapshots, logs, tool results, screenshots, and diagnostics;
• an alias-only audit receipt and deterministic availability preflight.

This complements the broader local secret-store request in #22029 and browser password-manager request in #32081. It does not request autonomous MFA, CAPTCHA bypass, plaintext retrieval by the model, or weaker account-security controls.

Current recurrence: sealed secret ingress and verified owner handoff remain separate hard blockers

This is an additional generic reproduction, not a claim that our custom Multi Server Sync owner-operations policy is a built-in Codex feature.

Environment

• Codex Desktop on Windows with a remote Linux browser host
• A custom runtime plugin that can declare host-local secret references and owner-assistance policy
• An explicitly authorized third-party login workflow

Generic reproduction

1. Start a task that must authenticate to a third-party website or approved child process.
2. Designate a customer-scoped credential in a host-local secret/password manager without placing its value in the prompt or repository.
3. Preflight the active Codex tool inventory.
4. Observe that there is no generic built-in sealed secret handle that can bind that selected item to one origin, workspace, field/tool call, and expiry.
5. Attempt an owner-direct interactive handoff instead.
6. If the owner surface is blank, inaccessible, or not verifiably attached to the exact live browser session, the short login window expires and the task cannot resume safely.

Actual behavior

• The model cannot safely consume the designated secret without a custom external broker or plaintext exposure.
• When that broker is unavailable, manual takeover becomes the only safe fallback.
• The fallback has no deterministic preflight proving that the owner can see and control the exact live session.
• A backend browser/tab or handoff request is not sufficient evidence that an actionable owner surface exists.
• The task remains blocked even though the user authorized the workflow; repeated retries add time and can create session-expiry or duplicate-action risk.

The blank-surface symptom may have several causes in a custom multi-host deployment, so I am not attributing a specific root cause to Codex core from this observation alone. The product gap is the absence of a first-class, verifiable fallback when the custom broker is unavailable.

Expected behavior

1. Provide a protected local input/picker or OS password-manager selector that returns only an opaque handle to the model.
2. Resolve the value only in the trusted local runtime and bind it to an exact workspace, origin or executable, input field/tool call, and short expiry.
3. Redact the value from model context, command lines, transcripts, shell snapshots, screenshots, logs, diagnostics, and tool results.
4. Preflight handle availability and scope before the authenticated workflow begins.
5. If direct owner action is required, surface a verified owner_action_required state tied to the exact live session, with an authenticated Take control action.
6. Treat the handoff as successful only after the owner-visible surface is confirmed interactive; preserve state, verify only that authentication cleared, and resume once.
7. Fail closed on timeout, revocation, or ambiguous concurrent sessions.

This does not request autonomous MFA, CAPTCHA solving, password disclosure to the model, or weaker third-party security controls.

Related scope:

• #22029 is the umbrella request for a generic local secret store.
• #25755 covers secure owner-in-the-loop protected-input handoff and session preservation.
• #37539 documents a separate blank browser-surface symptom; this comment does not assume the same root cause.

No customer, domain, account, credential, secret alias, OTP, screenshot, or private session detail is included.

Fresh reproduction: authorized secret store, but no callable credential binding

A fresh reproduction on 2026-08-21 confirms that this remains unresolved in an active Codex Desktop workflow.

Redacted scenario

• The user had already authenticated to a third-party public-service portal in an approved, separately managed browser session.
• Reading a protected record triggered a second password re-entry.
• The user explicitly authorized the selected host-local Google Secret Manager / password-manager route.
• Runtime preflight and live tool inventory exposed no opaque credential consumer and no mechanism binding a secret reference to that exact browser session and password field.
• The only available route was effectively owner-direct; no selectable, resolvable credential reference was available.
• No secret value was read (secretValuesRead: false), the password field remained blank, and the workflow could not proceed.

User impact

This presents as “Codex is refusing an explicitly authorized instruction,” although the observable cause is missing runtime capability and credential-to-session binding. Repeated owner handoffs are costly, often fail on remote hosts, and can delay time-sensitive public-service or legal workflows.

The gap also creates a perverse security incentive: users may add an unrestricted external agent or CLI solely to retrieve or copy passwords. A first-party opaque injection path would be safer because the model would never receive the plaintext.

Requested product behavior

1. Before browser launch, expose whether credential-store consumption is callable in the current session.
2. Provide a provider-neutral, host-local interface conceptually like:

useCredential({ secretRef, targetOrigin, browserSessionId, fieldSelector, purpose, ttl }).
The model should receive only a success/failure receipt, never the secret value.

1. Support adapters for secret-manager and password-manager providers with origin allowlisting, exact session/field binding, one-shot scope, short expiry, redaction, and alias-only audit records.
2. If the capability is unavailable, show an explicit “credential-consumption capability unavailable” result rather than behavior that appears to be a model refusal.
3. Do not advertise skills or policies that depend on authentication tools unless those tools are live and callable in the current session.

No credentials, account identifiers, portal details, case identifiers, screenshots, cookies, or session data are included here.

Cross-product observation: project-scoped external-agent fallback

This update records a user observation and product expectation, not a verified claim that another agent securely consumes Google Secret Manager or password-manager values.

Observed comparison boundary

• The user reports that Google Antigravity CLI (AGY) appears able to accept a task from an exact project workspace and autonomously complete authentication using a designated local/cloud credential source, without returning plaintext to the calling agent.
• A read-only local audit confirmed only that AGY can be launched from a selected working directory, supports one-shot noninteractive prompts, is signed by Google, and its current documentation describes browser-action permissions plus MCP/plugin extension points.
• That audit did not verify sealed GSM/GPM-to-browser injection. No login was attempted, no secret was read, no plugin was installed, and no raw credential path was tested. The observed installation had no imported plugin, so this should not be read as a security or feature claim about AGY.
• In the corresponding Codex reproduction, explicit owner authorization still did not produce a generic opaque credential consumer bound to the exact browser session and password field. The task therefore required repeated manual takeover or a separately engineered broker.

User impact

From the user's perspective, the product gap is practical: a project-scoped agent is expected to finish an authorized login task while keeping plaintext outside the caller, but Codex currently has neither a built-in sealed path nor a deterministic contract for delegating that one operation to a reviewed external agent.

The consequences include:

• paying for a secret-manager service but still being unable to consume the selected credential in the active workflow;
• additional IAM, cloud, MCP/plugin, and runtime maintenance for a custom broker;
• repeated owner interruptions and expired login windows;
• delays across multi-host, time-sensitive workflows; and
• pressure to introduce a less-reviewed external agent solely to bridge authentication.

Requested safe fallback

In addition to the first-party opaque-handle design already requested above, please consider a supported project-scoped external-agent adapter:

1. Codex sends only an approved purpose, exact workspace, origin, browser-session/field binding, TTL, and opaque secret alias.
2. A separately reviewed local agent or broker resolves and injects the value without returning it to Codex model context, chat, command lines, tool results, screenshots, or logs.
3. The adapter returns an alias-only, boolean/structured receipt covering binding, expiry, success/failure, and whether plaintext exposure occurred.
4. Codex preflights availability and policy compatibility before browser launch, and fails closed if the adapter, binding, or receipt is missing.
5. The UI clearly distinguishes a model refusal from a missing runtime capability.

This is not a request to bypass MFA, CAPTCHA, biometrics, consent, third-party account controls, or final-action confirmation. It is a request for a documented and auditable way to use a reviewed project-scoped agent or opaque broker when Codex cannot natively perform the authorized credential injection.

No credential, account, customer, domain, workspace path, screenshot, session identifier, or private project detail is included.

Implementation follow-up: the project-scoped fail-closed AGY opaque-login contract discussed above has now been merged in https://github.com/jyongchul/multi-server-sync/pull/876 (merge f32bed56c799f924be09ea1d30260c6d9ab460c0).

What this changes:

• separates raw credential entry by Codex (still prohibited) from an explicitly authorized reviewed opaque-broker authentication route;
• adds an exact-route validator bound to project, identity, provider domain, host, browser profile, lifecycle lease, AGY binary/version/hash/signature, nonce, and expiry;
• returns only digest/receipt metadata and never secret values;
• adds a project-folder AGY preflight that cannot dispatch AGY, open a browser, read a credential, or submit a form until the complete route is independently present;
• adds regression and public-catalog tests. All repository checks passed before merge.

Important current boundary: this is not a claim that autonomous login is working today. The installed AGY 1.1.17 audit found no imported plugins, no MCP servers, and no verified GSM/GPM-to-browser-field sealed consumer. Therefore the live route remains disabled and the preflight correctly returns NOT_READY instead of silently falling back to a human.

This confirms the product gap: a user may have an external project agent capable of credential handling, but Codex lacks a first-party, reviewed, provider-neutral way to delegate one exact password-field fill without exposing the secret to model output or logs. The practical result is repeated human-login interruptions and workflow paralysis even when the user has explicitly authorized the operation. A first-party opaque secret-to-field broker or reviewed project-scoped external-agent adapter remains needed; MFA, CAPTCHA, biometric, signature, consent, and final-submit boundaries should remain separate.

2026-08-25 recurrence: authorized login still could not be executed after nearly four hours

This is a fresh operational recurrence of the product gap described above. It is not a claim that our custom local policy is an OpenAI product policy.

An owner explicitly authorized Codex to update two time-sensitive posts on a third-party publishing service and to use an approved credential source or delegate the exact login step to a project-scoped external agent. A previous external-agent run had successfully created an authenticated browser state, but that state had expired. Later forensics showed that the successful historical route was an unsafe one-off script containing a credential literal, not a reusable opaque secret-manager consumer, so replaying it would have risked credential exposure.

In the current Codex session:

• no first-party sealed credential-to-browser-field capability was callable;
• the active runtime identity could not resolve the approved secret reference;
• a read-only external-agent capability audit was blocked before execution because the host runtime required a separate dispatch claim that Codex could not produce through any documented product interface;
• Codex therefore spent nearly four hours building and reviewing custom broker, lifecycle, cleanup, and persistence contracts instead of performing the authorized login;
• the two publishing operations remained unattempted, and the downstream customer completion notification could not be sent.

This is the practical failure mode the issue is trying to describe: the user has explicitly authorized the operation and has an approved credential source, yet Codex cannot deterministically establish a protected path from that source to one exact login field. The user experiences this as Codex refusing or avoiding the login, while the runtime keeps producing policy/preflight work rather than completing the task.

Please provide a supported product primitive with both of these options:

1. First-party sealed credential injection: select a secret/password-manager item in a protected UI, expose only an opaque expiring handle to the model, bind it to one workspace, origin, browser session, field and purpose, and return only a redacted success/failure receipt.
2. Verified project-scoped agent delegation: allow Codex to delegate one exact authentication operation to a reviewed local agent through a documented adapter, with deterministic preflight, explicit scope, expiry, lifecycle binding, and a receipt proving that plaintext never entered model context, chat, command lines, screenshots, logs or tool output.

The UI and tool result should clearly distinguish among model refusal, missing capability, unavailable credential provider, and owner action required. If a declared login skill depends on unavailable runtime machinery, that must be detected before the browser workflow starts—not after hours of custom contract work.

This request does not ask for CAPTCHA, MFA, biometric or third-party security bypass. It asks for a safe, auditable way to carry out an explicitly authorized ordinary password login without exposing the password to the model.

No customer, service, account, credential alias, secret value, browser state, workspace path, screenshot or private session identifier is included here.