Codex CLI 0.122.0: workflows, permissions, MCP

The situation

Codex CLI 0.122.0 is about making day-to-day work in real repos easier to control. The changelog points to a tighter loop around instructions, verification, MCP integrations, and permissions. That matters for engineering teams using OpenAI Codex on production codebases, where changes need to stay reviewable.

If you are running Codex in a shared repository, the useful question is not what the model can do. It is what the team should standardize so Codex can work safely, repeatably, and with diffs reviewers can trust.

For Codex CLI training and Codex workshop prep, the workflow lens is simple: what belongs in AGENTS.md, what belongs in MCP, what should be denied by policy, and how you verify the result before a pull request lands. That is the same idea behind our methodology: make a small, testable change, then document the review step.

Walkthrough

1. Start with the repo instruction chain. Codex reads AGENTS.md, and the changelog reinforces that instruction scope matters. Put durable repo rules at the root, then add nested files where a subdirectory needs different conventions. If you need a temporary exception, use an override file rather than editing the permanent policy.

---
name: repo-conventions
description: Repo rules for Codex CLI work in this service. Keep changes small, verified, and reviewable.
---

- Prefer the smallest change that fixes the issue.
- Run the project test command before asking for review.
- If a directory has its own `AGENTS.md`, follow the nearest file first.
- Do not modify generated artifacts unless the task explicitly requires it.

2. Make verification part of the task, not an afterthought. The 0.122.0 release emphasizes implementation in a fresh context for planning, plus visible context usage before you carry a thread forward. In practice, that means you should ask Codex to produce a change, then run the repo’s own checks, then inspect the diff. A good team habit is to require a short verification note in the PR description: what changed, what command was run, and what still needs human review.

1. Read AGENTS.md and the nearest nested instructions.
2. Make the smallest code change.
3. Run the project test or lint command.
4. Inspect the diff for scope creep.
5. Open a reviewable PR with the verification command recorded.

3. Treat MCP as a boundary, not a convenience layer. The release adds more plugin and marketplace flexibility, but the operational lesson is still least privilege. If a connector can reach external systems, define what it may read, write, or trigger. Keep that review separate from code review. For Codex teams, an MCP boundary note should answer: which tools are allowed, which repos or services they touch, and what approval is required before a connector is enabled in a workspace.

4. Use the new workflow affordances to reduce context switching, but keep them narrow. Side conversations, queued slash commands, and shell prompts while work is running can help when you need a quick clarification without abandoning the main task. The tradeoff is obvious: more concurrency can also mean more partial context. Use these features for small questions, not for redesigning the task midstream.

5. Revisit permissions and sandboxing as part of rollout. The changelog calls out deny-read glob policies, managed deny-read requirements, platform sandbox enforcement, and isolated exec runs that ignore user config or rules. That is a strong signal to review what Codex can see before you let it touch a sensitive repo. Teams should check whether their default workspace assumptions still hold on Windows, Intel Macs, and standalone installs.

Tradeoffs and limits

The new flexibility is useful, but it increases the need for policy discipline. More plugin sources and connector options can make setup easier while also widening the review surface. If your team does not maintain a clear allowlist, you can end up with tools that work in one workspace and fail or overreach in another.

The same applies to planning and side conversations. Fresh-context implementation can improve focus, but it can also hide assumptions if the planning thread is not carried forward deliberately. Use it when you want a clean implementation pass; avoid it when the task depends on long-lived architectural context.

Security changes are helpful, but they do not replace local review. Deny-read rules, sandbox enforcement, and trusted-workspace checks reduce exposure; they do not tell you whether the change is correct. Keep the human review step on the critical path, especially for connector-enabled work and anything that touches credentials, hooks, or project policies.

A practical starter checklist for Codex teams:

• Add or audit root and nested AGENTS.md files.
• Write one verification command for each common task.
• Document MCP permissions before enabling a connector.
• Decide which workspaces are trusted for hooks and exec policies.
• Require a reviewable diff plus a test result before merge.

Further reading

• https://developers.openai.com/codex/changelog
• https://developers.openai.com/codex/cli
• https://developers.openai.com/codex/guides/agents-md
• https://developers.openai.com/codex
• https://modelcontextprotocol.io/introduction
• /topics/cli-workflows