04 | Codex Project Instructions and Permissions: Set Boundaries with AGENTS.md

Configuration is about boundaries, not volume

The upstream guide separates project instructions, permissions and sandboxing, config.toml, Rules, and Hooks. They serve different purposes: instructions explain the project; permissions and sandboxing constrain actions; Rules establish harder command boundaries; Hooks run scripts at specified events.

Do not begin by exploring every setting. Begin with a short, testable AGENTS.md in the project root.

What belongs in the first AGENTS.md

Useful rules support a stable workflow. The upstream examples cover project context, common commands, code style, tests, and safety:

# Project rules

## Commands
- Run the relevant test before and after a change.

## Code style
- Prefer small, focused changes and follow existing patterns.

## Safety
- Do not edit secrets, deployment configuration, or generated files without approval.

Add goal-driven execution, simplicity, surgical changes, and explicit verification requirements. That is enough to make early collaboration predictable.

Do not turn it into an encyclopedia

AGENTS.md should not contain stale background, temporary chat history, unrelated preferences, or contradictory long lists. More rules do not automatically mean stronger control; unverifiable rules create ambiguity.

Large repositories can use layered AGENTS.md files so rules sit near the directories they govern, while project-level boundaries remain shared.

Verify permissions and configuration

Find the permission controls in the App and understand the sandbox’s allowed and restricted actions. Move to config.toml, Rules, or Hooks only when you need finer control. After any change, ask Codex what rules it read, run a low-risk task, and check that it honored prohibited actions and test requirements.

Configuration is a living agreement refined through real failures, review, and handoff—not a one-time document.