OpenAI Codex for beginners: let the agent explain the code first

Have you ever opened a small website folder, an old script, or a course project and thought: "I want to change one thing, but I barely dare touch the files"? OpenAI Codex can be a useful next step after normal ChatGPT. But do not begin by asking the agent to rebuild everything. Ask it to explain the project first.

OpenAI Codex is a coding agent: it can work inside a project, read files, propose edits, and help you review the result. It does not replace your judgment. The point of this first guide is to keep control: small task, clear permissions, diff review, and a simple check before you keep anything.

Source: OpenAI Codex developer overview and OpenAI Codex quickstart.

Who this guide is for

This guide is for you if you have tried ChatGPT, Claude, Gemini, or a Custom GPT and now want to understand what an AI agent can do with code. You do not need to be a professional developer. You do need a small first project: a copy of a simple website, an exercise repo, a course project, or a short internal script.

Wednesday's guide on Copilot Notebooks was about collecting project sources in Microsoft 365. This is different. Here the source material is code, the output is a proposed change, and the human reviews the diff before accepting anything.

What you will learn in 10-20 minutes

By the end, you can:

• find a reasonable first way into Codex,
• choose a small project that is not sensitive,
• ask Codex to explain the files before it edits anything,
• request one small reversible change with clear criteria,
• review the diff, meaning the before/after view of changed files,
• test or check the result before keeping it.

Where do you find OpenAI Codex?

OpenAI describes several Codex entry points: app, IDE extension, CLI, and web/cloud. For a first exercise, the simplest story is often local: open the Codex app if it is available on your machine, sign in with your ChatGPT account, and choose a small project folder.

If you use the browser route, go to https://chatgpt.com/codex. That path is more connected to GitHub repositories and cloud environments, so do not let it become the first rabbit hole if you only want to learn the workflow. Access, limits, and workspace settings can differ across accounts, plans, and managed workspaces.

Source: Codex quickstart, Codex app, and Codex cloud.

Before you start: choose a small controlled project

Do not choose production code for the first run. Use a copy, a sample project, or a small folder where testing is fine. If the project already uses Git, save a checkpoint or commit before you start, so changes are easier to see and undo.

Keep the boundaries clean. Do not include .env files, API keys, customer data, production passwords, or private code you do not have permission to use. This is not about avoiding integrations forever. It is about making the first integration legible: a bounded folder, clear permissions, approval before Codex leaves the task, and a log/diff a human can review.

Source: Codex sandboxing, agent approvals and security, and Codex permissions.

Step 1: open a small project

Start Codex and choose one small project folder or repo. If you work locally, the goal is simply to let Codex see the project and understand the context. If you use the cloud flow, GitHub and environment settings may be involved, but save that detail for later if it distracts from the first exercise.

Good first examples:

• a simple landing page where you want to change text or a button,
• a course project where you want to understand the files,
• a small script that creates a report,
• a copy of a demo repo where nothing customer-critical is at stake.

Step 2: ask Codex to explain before editing

Paste this prompt first:

Explain this project before changing anything.

Please:
1. Describe what the project does in plain language.
2. List the 5-8 most important files or folders.
3. Tell me how I would run or preview it, if the project includes that information.
4. Point out anything that looks risky, unclear, or missing.
5. Do not edit files yet.

Read the answer as if a colleague were walking you through the project. Still confused? Ask Codex to simplify, compare the structure to something familiar, or tell you which file to read first.

Step 3: ask for one safe first change

Once the explanation makes sense, ask for a proposal. Keep the task small.

Suggest one small, reversible improvement for this project.

Context:
- I am a beginner and want to review the change carefully.
- Keep the change limited to [one file / one component / one text update / one small bug fix].
- Do not touch secrets, environment variables, deployment settings, or unrelated files.

Before editing, give me:
1. the exact change you propose,
2. why it is safe and useful,
3. what files it would touch,
4. how we will verify it.

Done when: I can inspect the diff and decide whether to keep or revert it.

If Codex proposes too much, stop there. Write: "Make the task smaller. Choose one file and one clear change." It is a good sign when the agent can be steered back down.

Source: Codex prompting and Codex best practices.

Step 4: approve only the small change

When the plan is understandable, let Codex make that change only. If it asks for network access, full access, or permission to edit files outside the project folder, ask why. For a first exercise, the answer is often: no, not yet.

A good beginner rule: Codex may read and propose, but it should not get more freedom than the task needs. In a real team, the same idea becomes a simple operating routine: scoped permissions, secrets in a secret manager or environment variables outside the chat, approval steps, logs, and diff review.

Step 5: review the diff before accepting

A diff is the before/after view of what changed. Look for things that do not belong:

• new files you did not ask for,
• changed settings,
• new dependencies,
• removed comments or checks,
• edits across several parts of the project when you asked for one small thing.

If something feels too large, comment or send a follow-up:

Keep the scope smaller. Address only the comments I left in the diff. Do not change unrelated files.

Source: Codex review pane.

Step 6: verify before you keep the change

Ask Codex for the smallest useful check. It might be a test command, lint, local preview, or a manual checklist. If you do not know how to run the project, ask Codex to explain the check step by step.

Suggest the smallest check to verify this change.
If the project includes test, lint, or preview commands, show them.
If I cannot run them, give me a manual checklist.

Keep or commit only what you actually want. Revert the rest. It sounds slow, but it is faster than trying to understand later why an AI agent changed five files when you asked for one button label.

Reusable first Codex task card

Save this prompt for your next small task:

You are helping me with my first small Codex task.

Rules:
- Explain before editing.
- Keep the task small and reversible.
- Do not touch secrets, .env files, deployment settings, or unrelated files.
- Ask before using network access or leaving the project folder.
- Mark anything uncertain as "needs human check".

Task:
1. Explain the project in plain language.
2. Suggest one safe first improvement.
3. Show which files would change.
4. Wait for approval before editing.
5. After editing, summarize the diff and tell me how to verify it.

Common mistakes

The most common mistake is starting too large: a production repo, a vague prompt like "fix everything," or full access because an online tutorial did it. Another mistake is trusting the output because it sounds confident. Code still needs review.

Avoid mixing every Codex surface in the first session too: app, CLI, IDE, cloud, GitHub, AGENTS.md, MCP, worktrees, and automations. The first session should teach the rhythm: explanation, small plan, approval, diff, check.

Next step

If the first exercise works, create a small project note, or later an AGENTS.md, with how the project runs, how it is tested, and how changes should be reviewed. That is a good next step because Codex has to guess less next time.

Want to test coding agents in a controlled way for a team or business? Hammer can help you choose a small first repo, set simple permission rules, and build a routine for explanation, planning, diff review, testing, and human approval.

The next natural guide in the series could be Codex with AGENTS.md or a first light Claude Code guide, depending on reader and Shorts data.