5-min read · Written by an AI Systems Architect
Focus: Getting started with OpenAI Codex safely
The One Thing to Get Right First
Codex is not ChatGPT.
ChatGPT is a chat window — you ask, it answers, the conversation ends there.
Codex is someone sitting inside your project directory, working alongside you. It can:
- Read your entire codebase
- Modify files
- Run commands and tests
- Show you exactly what it changed (the diff)
The golden habit for beginners: Don't ask it to "build the whole thing." Instead:
Read first → Propose a plan → Change one small thing → Review the diff → Run tests → Repeat
Let me walk you through exactly how to do this, using three tasks.
The Right Entry Point (Pick One)
Codex has four ways to use it. Here's how to choose:
| Entry Point | Best For | How to Start |
|---|---|---|
| Codex App ⭐ | Beginners | Desktop app, pick a project folder, send tasks |
| IDE Extension | VS Code / Cursor / JetBrains users | Open from sidebar |
| CLI | Terminal users | Run Codex from the command line |
| Web / Cloud | GitHub automation | Cloud execution, auto-PR |
My recommendation: Start with the Codex App. Download it, log in with your ChatGPT account (no API key needed), and pick a small project to practice on.
Task 1: Read First, Don't Touch Yet
This is the most common beginner mistake — asking Codex to do something huge right away.
Don't do this:
"Refactor my entire project."
"Build a complete website."
"Fix all the bugs."
Do this instead — copy this prompt:
Please don't modify any files yet. Explain this project to me in simple terms:
1. What does this project do?
2. What are the main directories for?
3. Where's the entry point?
4. What commands do I need to run it?
5. What are you unsure about? Just say "not sure" — don't guess.
This is your first task: have Codex read the project first, then you decide what to do next.
Task 2: Write Better Prompts with the 4-Element Framework
The official Codex docs recommend a four-element prompt structure. It's simple but makes a huge difference:
| Element | What You Tell Codex |
|---|---|
| 🎯 Goal | What you want to accomplish |
| 📁 Context | Which files, errors, or screenshots are relevant (use @file) |
| ⛔ Constraints | What's off-limits (no new deps, don't touch APIs) |
| ✅ Done when | How to verify success (tests pass, diff is clean) |
Bad vs. Good
| ❌ Bad | ✅ Good |
|---|---|
| "Optimize my checkout flow" |
Goal: Reduce duplicate payment validation in src/checkout/
|
Context: Files in src/checkout/ and src/orders/validation.ts
|
|
| Constraints: Don't change public API response format, no new deps | |
Done when: pnpm test --filter checkout passes, diff in src/checkout/ only |
Choosing the Right Reasoning Level
| Level | When to Use |
|---|---|
| Low 🏃 | Quick, well-defined tasks |
| Medium ⭐ | Daily default — best balance |
| High 🧠 | Complex changes or debugging |
| Extra High 🚀 | Long-running agentic tasks |
Task 3: Your First Code Change — Just Edit README
After Codex understands the project, make one tiny change.
Copy this prompt:
Please only modify README.md. Add a section called "How to Get Started."
Rules:
- Don't touch any other files.
- Don't install new dependencies.
- Don't change any code.
- After changing, tell me what you changed.
- If the project doesn't have explicit start commands, just say "not sure."
After Codex runs these two commands:
git status # See which files changed
git diff # See exactly what changed
What to check in the diff
- ✅ Did Codex touch files you didn't allow?
- ✅ Did it introduce unfamiliar dependencies?
- ✅ Did it delete important configuration?
- ✅ Does the content meet your requirements?
As a beginner, you don't need to understand every line of code. Just learning to check "which files changed" will prevent most problems.
Safety: Don't Give It Full Access From Day One
| Mode | What It Does | Beginner's Rule |
|---|---|---|
| Chat / Read Only | Explain, answer, plan | ✅ Start here |
| Agent / Auto | Small changes, run tests | ✅ Review the diff first |
| Full Access | Cross-directory, network, complex tasks | ❌ Don't default to this |
Never paste these into prompts:
- ❌ API keys, database passwords, production tokens
- ❌ Customer or personal data
- ❌ Production database connection strings
- ❌ Error logs without checking them first (they can contain tokens and secrets)
The Life-Saving Git Checkpoint
# Before Codex works:
git add .
git commit -m "checkpoint before codex task"
# After Codex finishes:
git status
git diff
🛡️ Never let Codex make big changes in production projects without a backup.
7-Day Practice Plan
| Day | Task | Goal |
|---|---|---|
| 1 | Read-only, explain the project | Understand what it is |
| 2 | Write docs/project-overview.md (no code changes) |
Practice documentation |
| 3 | Edit README.md only | Practice reviewing diffs |
| 4 | Fix one small bug with error + repro steps | Learn to describe issues |
| 5 | Add a minimal test for the fix | Let Codex verify itself |
| 6 | Code review uncommitted changes | Codex as a second pair of eyes |
| 7 | Implement a small feature in a worktree | Learn isolated environments |
Appendix: Copy-Paste Prompt Templates
The 4-Element Universal Template
Goal: What do you want to accomplish?
Context: Which files, errors, or screenshots are relevant?
Constraints: What's off-limits? (no new deps, no API changes)
Done when: How will you verify success?
Read a Project Template
Please don't modify files. Help me understand this project:
1. What does it do? 2. Tech stack? 3. Entry point?
4. Directory purposes? 5. Reading order for beginners? 6. What are you unsure about?
Fix a Bug Template
I have a bug. Please find and fix it.
Symptom: [paste error] Steps to reproduce: [steps]
Requirements: Explain the root cause → minimal change → no new deps → run tests → list changed files and risks.
Code Review Template
Review the uncommitted changes.
Focus on: bugs, edge cases, regressions, security/performance risks, missing tests.
List high-risk issues first, then medium/low. Don't modify anything.
UI Task with Screenshot Template
Implement a page matching the attached screenshot.
Requirements: Use existing tech stack → match layout and spacing → don't add UI libraries without asking → minimal components → show me how to preview it.
Start with Codex the right way:
Read the project → Get a plan → Change one small thing → Review the diff → Run tests → Repeat.
Keep tasks small, permissions tight, and verification clear — and you'll use Codex safely from day one.
Top comments (0)