What variant of Codex are you using?
App
What feature would you like to see?
I would like Codex to provide a local secret management feature for sensitive information such as server usernames, passwords, API keys, SSH credentials, database passwords, and deployment tokens.
In many real-world workflows, Codex may need to execute commands that require credentials. However, users may not want those credentials to be included in prompts or sent to the model server. It would be much safer if Codex allowed users to configure secrets locally and reference them by name.
For example, a user could define local secrets such as:
prod-server-username prod-server-password staging-db-password github-deploy-token
Then, when Codex needs to run a command, the model would only see a reference such as:
${secrets.PROD_SERVER_PASSWORD}
The actual secret value would only be resolved locally by the Codex runtime at execution time. The plaintext value should never be included in the prompt, model context, logs, or tool-call descriptions sent to the remote model.
Suggested capabilities:
A local secret store for creating, updating, deleting, and listing secret aliases.
Secret references that can be used in commands, MCP tool calls, scripts, or environment variables.
Runtime-only resolution, where secrets are injected locally during execution.
Confirmation prompts before a secret is used, especially the first time or for high-risk operations.
Project-scoped, workspace-scoped, global, and session-only secrets.
Audit logs that record which secret alias was used, without recording the actual value.
Redaction of secret values from terminal output, logs, conversation history, and debugging traces.
Support for injecting secrets as environment variables, temporary files, stdin, or command arguments when appropriate.
A clear security boundary where the model can request a secret by alias, but cannot read or print the secret value directly.
The goal is to make Codex safer for real engineering, operations, deployment, database, and infrastructure workflows. Users should be able to let Codex perform authenticated local actions without exposing sensitive credentials to the model server.
This would be similar in spirit to how CI systems manage secrets: the workflow can reference a secret by name, but the secret value is only resolved inside the trusted execution environment.
Short Version
Please consider adding a local secret management feature to Codex. Users could store sensitive credentials locally and reference them by alias. Codex would resolve those secrets only at local execution time, while the model would see only placeholder references and never receive the plaintext secret values. This would make Codex much safer for tasks involving servers, databases, deployments, private APIs, and infrastructure automation.
Additional information
No response
What variant of Codex are you using?
App
What feature would you like to see?
I would like Codex to provide a local secret management feature for sensitive information such as server usernames, passwords, API keys, SSH credentials, database passwords, and deployment tokens.
In many real-world workflows, Codex may need to execute commands that require credentials. However, users may not want those credentials to be included in prompts or sent to the model server. It would be much safer if Codex allowed users to configure secrets locally and reference them by name.
For example, a user could define local secrets such as:
prod-server-username prod-server-password staging-db-password github-deploy-tokenThen, when Codex needs to run a command, the model would only see a reference such as:
${secrets.PROD_SERVER_PASSWORD}The actual secret value would only be resolved locally by the Codex runtime at execution time. The plaintext value should never be included in the prompt, model context, logs, or tool-call descriptions sent to the remote model.
Suggested capabilities:
A local secret store for creating, updating, deleting, and listing secret aliases.
Secret references that can be used in commands, MCP tool calls, scripts, or environment variables.
Runtime-only resolution, where secrets are injected locally during execution.
Confirmation prompts before a secret is used, especially the first time or for high-risk operations.
Project-scoped, workspace-scoped, global, and session-only secrets.
Audit logs that record which secret alias was used, without recording the actual value.
Redaction of secret values from terminal output, logs, conversation history, and debugging traces.
Support for injecting secrets as environment variables, temporary files, stdin, or command arguments when appropriate.
A clear security boundary where the model can request a secret by alias, but cannot read or print the secret value directly.
The goal is to make Codex safer for real engineering, operations, deployment, database, and infrastructure workflows. Users should be able to let Codex perform authenticated local actions without exposing sensitive credentials to the model server.
This would be similar in spirit to how CI systems manage secrets: the workflow can reference a secret by name, but the secret value is only resolved inside the trusted execution environment.
Short Version
Please consider adding a local secret management feature to Codex. Users could store sensitive credentials locally and reference them by alias. Codex would resolve those secrets only at local execution time, while the model would see only placeholder references and never receive the plaintext secret values. This would make Codex much safer for tasks involving servers, databases, deployments, private APIs, and infrastructure automation.
Additional information
No response