Local Secret Store for Sensitive Credentials

Windows reproduction showing why this needs a broker rather than broader plaintext access:

• Platform: Windows 10 22H2, build 19045, 64-bit.
• Bundled Browser/Computer Use plugin generation: 26.803.41515. Desktop package version was not available from the local package query.
• A user had already stored an API key in the Windows user environment and explicitly authorized an agent to start a local API-key-protected MCP server plus an existing test-only development tunnel.
• The model did not need the value and did not ask to print it. The desired operation was: resolve one named secret locally, inject it only into the child process environment, start the approved executable, and record only that the alias was used.
• The command boundary rejected reading the user-scoped value and injecting it into the background process. The safe alternative—starting the relay without authentication—was correctly rejected, so the otherwise automated Copilot Studio verification stopped.
• User authorization in chat cannot currently grant a scoped secret handle, and there is no Settings surface for approving an alias for one workspace/executable/action.

This is a concrete fit for the proposed local secret store. Useful acceptance criteria from this case:

1. User creates or imports a secret alias locally and approves it for an exact workspace plus executable/script.
2. The model sees only the alias and whether it is available.
3. Runtime injects the value into environment/stdin/secure parameter binding without placing it in the model request, tool-call text, process command line, logs, proof artifacts, or shell history.
4. First use and scope expansion require action-time approval; aliases can expire or be revoked.
5. Audit records alias, target, time, and outcome, never value.
6. Background-process launch is supported so secret-backed local MCP servers and deployment helpers do not require a human terminal step.
7. Redaction covers child stdout/stderr and tool diagnostics.
8. Browser/password-manager and account-tile workflows remain separate permissioned surfaces; see #32081 and #37512.

No credential, endpoint, account, tenant, or repository identifier is included in this report.

Concrete user impact and acceptance criteria from Codex 0.147.0:

The current manual documents OS keyring storage for Codex login and MCP OAuth credentials, environment-variable forwarding, and command-backed model-provider authentication. Those are useful but do not provide a generic protected secret ingress for an arbitrary local tool or third-party website.

Minimal secret-free reproduction:

1. Create a fictitious required credential alias, for example TEST_LOGIN_PASSWORD, without storing any value in the prompt or repository.
2. Ask Codex to run an explicitly approved authenticated child process or sign in to a test website using a user-selected OS password-manager item.
3. Try to supply the value through a protected one-time prompt, or select the item and expose only an opaque handle to the agent.
4. There is no generic built-in surface for that handoff. The operator must build an external secret broker/environment integration or manually take over the login.

In our deployment, this forces use of a custom Google Secret Manager/MCP bridge. The consequence is not just setup inconvenience: it adds secret-manager cost, IAM/network configuration, plugin/runtime maintenance, and another availability dependency. When that integration is missing from an active session, long-running work stops for repeated human login handoffs and short-lived login windows expire.

Important scope clarification: our rule that treats credentials pasted into a conversation as compromised input is a local Multi Server Sync policy, not a behavior I am attributing to OpenAI Codex. The requested capability is valuable regardless: it gives users a supported alternative that keeps plaintext outside model context.

Suggested acceptance test:

• Import or enter a session-only secret through a protected local UI/CLI, or select an OS password-manager item.
• The model receives only an opaque alias/handle and availability metadata.
• The user binds it to one workspace plus origin/executable/tool call and a short expiry.
• The runtime injects it through environment, stdin, temporary file, HTTP header, or browser autofill without placing the value in command lines, model requests, transcripts, shell snapshots, screenshots, logs, or tool results.
• First use and scope expansion require approval; revoke/expiry is immediate.
• Audit output records alias, target, timestamp, and success/failure only.
• A preflight reports whether the capability is available before an authenticated workflow begins.

Related narrower reports: #32081 for browser/password-manager autofill and #37695 for runtime capability preflight. This issue remains the best umbrella for the generic local secret-ingress primitive.

Quantified follow-up on the operational cost of the current workaround (sanitized; no project, account, billing, secret-name, or secret-value identifiers):

Our local integration uses Google Secret Manager as an external broker because Codex does not currently provide a generic protected one-time secret-ingress surface or an opaque, runtime-resolved secret handle for arbitrary approved tools and browser actions.

A read-only inventory across two projects found:

• 629 secret objects.
• 870 active secret versions in total. This count includes both Enabled and Disabled versions.
• Google provides 6 active versions free per billing account and charges about $0.06/month for each additional active version. Therefore, (870 - 6) × $0.06 ≈ $51.84/month is the estimated storage base before access-operation charges.
• The retained audit-log query returned 0 AccessSecretVersion entries for the inspected period. This is not evidence that actual access was zero, because Secret Manager Data Access logging may not have been enabled or retained.

Google's official pricing page confirms that pricing is based on active secret versions and access operations, that both Enabled and Disabled versions are active/billable, and that destroyed versions are free: https://cloud.google.com/secret-manager/pricing

This is not a claim that ChatGPT or Codex directly imposed the Google charge. OpenAI's official authentication documentation describes Codex access through either ChatGPT subscription sign-in or API-key usage-based access: https://learn.chatgpt.com/docs/auth. The cost above is an external integration cost created by the combination of our local secret-broker design and the absence of a generic Codex secret-ingress/opaque-handle primitive.

The measured impact strengthens the request in this issue. A useful native design would let a user:

1. Enter or select a secret through a protected local UI/CLI that is never placed in model context, transcripts, tool arguments, screenshots, or logs.
2. Give the model only an opaque handle plus availability/scope metadata.
3. Bind use to one workspace, origin/executable/tool action, field or injection channel, and short expiry.
4. Resolve and inject locally through environment, stdin, a temporary file, HTTP header, or approved browser autofill.
5. Require approval for first use and scope expansion, support immediate revocation, and produce alias-only audit events.
6. Support a provider interface for OS keyrings/password managers/external vaults without forcing users to create and retain one separately billed cloud secret version for every credential and rollback.

Even when an external vault remains appropriate for machine credentials, a native protected ingress and opaque-handle contract would reduce credential sprawl, repeated human handoffs, duplicated versions, and vendor-specific broker maintenance while preserving the boundary that plaintext must not reach the model.