Install OpenAI Codex CLI Safely

Install first, but do not treat installation as the workflow. OpenAI's Codex CLI should be set up inside a repository with clear AGENTS.md instructions, narrow MCP access, and a verification loop your team already trusts.

Record the OpenAI Codex CLI install step in the repo, then make the first task small enough to review. In a Codex workshop or OpenAI Codex training room, I keep the setup tied to real CLI workflows: read the repo rules, make one scoped change, run the checks, and leave evidence for the next developer.

Use the official install path and write down the team rule

As of November 2026, use OpenAI's Codex CLI docs as the authority for the current install command. Do not copy an old shell snippet from a chat, a slide, or a stale onboarding note.

A team install procedure should be short and repeatable:

1. Follow the current Codex CLI install and authentication steps from OpenAI's docs.
2. Run Codex from the repository root unless a nested package has its own AGENTS.md.
3. Add or update AGENTS.md before asking Codex to change code.
4. Start with an inspect-only task so the agent reads the repo without writing files.
5. Make one small change, then run the same verification commands a developer would run before a pull request.
6. Paste the commands and results into the pull request or issue handoff.

This keeps the install from becoming personal machine folklore. It also gives new team members one place to look when Codex behaves differently across machines.

Put repository rules in AGENTS.md

Codex needs local rules more than it needs a longer prompt. Put durable conventions in AGENTS.md: package manager, test commands, architecture boundaries, naming rules, and what the agent must not touch without asking.

Use nested AGENTS.md files when parts of the repo behave differently. A frontend package might use Playwright and pnpm, while a backend service uses a different test runner. Local scope beats one flat root file when the repo is large.

For a real workflow, think of a pnpm monorepo where a change in apps/web must not rewrite shared database code in packages/db. The root AGENTS.md can say how the repo is organized, while apps/web/AGENTS.md can name the exact lint, typecheck, and test commands for that app.

If you want the broader team pattern, I wrote more about this in Use Codex CLI as a Team Tool.

Add MCP access after the first safe loop

When you add MCP, treat it as access to outside systems, such as GitHub, Jira, a database, or an internal document store. Start read-only where the server allows it, then add write actions only after the team has reviewed how Codex uses the context.

The limit is practical. A broken code edit is visible in git. A bad write to an issue tracker, database, or release note can leave the repo clean while the workflow is still damaged.

Write the boundary down. For example: Codex may read linked issues and pull request comments through MCP, but it may not create tickets, change labels, post comments, or update release notes unless a human explicitly asks in that task.

Make verification part of the prompt

A Codex agent can produce a reasonable diff and still miss the contract your repo cares about. The fix is not a bigger prompt. The fix is a small verification loop that runs every time.

For a web change, that might be pnpm lint, pnpm typecheck, and one targeted test command. For a migration change, it might include a dry run and a rollback check. This is the Review step in our methodology: make the agent prove its work with the same commands a developer would run.

Keep the loop short at first. If verification takes twenty minutes, developers will skip it during exploration and run it too late.

Paste this AGENTS.md starter

Use this as a starter, then replace the commands and boundaries with the ones your repo actually uses.

# AGENTS.md

## Repository rules
- Use the package manager already locked in this repo.
- Keep changes inside the package or service named in the task.
- Do not rewrite public APIs, migrations, auth logic, or release files without asking first.
- Prefer small diffs that a reviewer can understand in one pass.

## Codex CLI workflow
- Start by reading this file and any nested AGENTS.md files in the working directory.
- Before editing, summarize the files you plan to touch and why.
- After editing, show the diff summary and list any files you intentionally left unchanged.

## MCP boundary
- MCP may be used to read linked issues, pull requests, docs, and design notes.
- Do not create, edit, comment, label, merge, deploy, or publish through MCP unless the task explicitly asks for that action.
- If external context conflicts with repository code, stop and ask which source should win.

## Verification
- Run the smallest relevant checks before handing work back.
- For frontend changes, run: pnpm lint && pnpm typecheck
- For targeted tests, run the test file or package affected by the change.
- If a command fails, report the exact command, the failure, and whether you changed code after the failure.

The main tradeoff is maintenance. A stale AGENTS.md is worse than no rule for a specific package, because it gives Codex confidence in the wrong instruction.

Further reading

• Codex CLI docs
• Codex CLI features
• Codex slash commands

Put this into one repo

Pick one service, add the install note and AGENTS.md starter, then run one small Codex CLI task through the verification loop. Our hands-on training for Codex CLI workflows uses the same pattern in a guided engineering session.