Config
Design Codex configuration layers, profiles, and safe defaults for team usage.
Key takeaways
- Configuration's job is to make the safe path the default path, not to expose every option.
- Layer config by owner: user defaults, repository rules, team policy, and admin policy that cannot be weakened locally.
- Define purpose-built profiles such as
default,review,automation, andrestrictedfor sensitive work. - On review, confirm explicit sandbox and approval defaults, gated high-risk tools, and a migration note whenever config changes.
- Validate named permission profiles with
codex sandbox -P <profile>, inspect effective modes via/debug-config, and include plugin marketplace JSON in supply-chain audits.
Configuration turns team preferences into repeatable behavior. The goal is not to expose every option; it is to make the safe path the default path.
Config Layers
| Layer | Purpose | Owner |
|---|---|---|
| User config | Personal defaults and editor preferences | Developer |
| Repository config | Project rules, commands, and context | Repo owner |
| Team config | Shared policy, model, and permission defaults | Engineering lead |
| Admin policy | Requirements that cannot be weakened locally | Platform or security |
Profile Design
| Profile | Use |
|---|---|
default | Normal development and documentation |
review | Read-heavy code review and analysis |
automation | Non-interactive commands with tight scope |
restricted | Sensitive repositories or production-adjacent work |
Review Checklist
- Are sandbox and approval defaults explicit?
- Are model and reasoning defaults appropriate for cost and quality?
- Are extra read directories intentionally allowed?
- Are high-risk tools disabled or gated?
- Is there a migration note when config changes?
- Can the team validate named permission profiles with
codex sandbox -P <profile>and inspect effective sandbox modes with/debug-config? - Are plugin marketplace JSON outputs included in config and supply-chain audits?