## Why
CLI auth and MCP OAuth credentials should use separate encrypted files
while sharing the existing local-secrets implementation and
OS-keyring-backed encryption key mechanism.
This is the second PR in the encrypted-auth stack:
1. #27504 — feature and config selection
2. This PR — auth-specific local-secrets namespaces
3. CLI auth implementation and activation
4. MCP OAuth implementation and activation
## What Changed
- Added `LocalSecretsNamespace` variants for shared secrets, CLI auth,
and MCP OAuth.
- Selected `local.age`, `cli_auth.age`, or `mcp_oauth.age` from the
namespace.
- Made atomic temporary filenames derive from the selected secrets
filename.
- Added namespaced `SecretsManager` construction and coverage proving
the auth namespaces write separate encrypted files.
- Made the default keyring store clonable for downstream namespaced auth
backends.
This PR does not activate either auth backend or change existing
credential behavior.
## Validation
- `just test -p codex-secrets` — 7 passed
- `just test -p codex-keyring-store` — package has no test binaries
- `just fmt`
## Summary
This introduces the first working foundation for Codex managed secrets:
a small Rust crate that can securely store and retrieve secrets locally.
Concretely, it adds a `codex-secrets` crate that:
- encrypts a local secrets file using `age`
- generates a high-entropy encryption key
- stores that key in the OS keyring
## What this enables
- A secure local persistence model for secrets
- A clean, isolated place for future provider backends
- A clear boundary: Codex can become a credential broker without putting
plaintext secrets in config files
## Implementation details
- New crate: `codex-rs/secrets/`
- Encryption: `age` with scrypt recipient/identity
- Key generation: `OsRng` (32 random bytes)
- Key storage: OS keyring via `codex-keyring-store`
## Testing
- `cd codex-rs && just fmt`
- `cd codex-rs && cargo test -p codex-secrets`