Codex can read your files, change them, use tools, and run checks. But most people get stuck in the same loop: ask, get something half-right, ask again, repeat.
You can break that loop with three habits:
- Tell it what you want at the end.
- Show it where the right info is.
- Make it prove the work is done.
Here’s how to do each one, plus a few tricks that save time and usage.
1. Say what “done” looks like
“Make my website better” could mean anything. New colors? Faster pages? Better text? A full redo? The more Codex has to guess, the more likely it guesses wrong.
A good request answers four questions:
- What do you want?
- What should it look at?
- What should it not touch?
- How will you know it’s finished?
Small jobs only need one sentence. Bigger jobs need more detail. OpenAI’s own guide says the same thing: start with the result you want, then add what matters. OpenAI prompting guide
For writing, try:
Turn the interview notes in this folder into an article for people new to this industry. Keep the source for every number. Mark anything you can’t confirm. Give me the final file, and check for repeated parts or things that contradict each other.
For fixing a page:
On phones, the buttons at the top of this page are squished together. Find out why and fix it. Don’t break anything else. Then open the page at phone size, make sure the buttons work and no text is cut off, and tell me what you changed.
That last line is the important part. It turns “change something” into “hand me something you’ve checked.”
One more trick: give it one example of a right result and one thing that must never happen. For example: “People can view an order as many times as they want, but they must never be charged twice.” Hacker News discussion
2. Big job? Plan first. Small job? Just do it.
Building a whole site, sorting a pile of messy files, or changing something that touches lots of places? Ask Codex to look around first and make a plan.
Look at what we already have first. Find the questions that would change how we do this. Break the work into steps I can check one at a time, and say what each step delivers. If you can find an answer yourself, find it. Only ask me about things that change the direction and that you really can’t figure out.
If you’re still deciding the direction, ask to see the plan before it starts. If you already know what you want, let it work step by step and check as it goes. You don’t need to type “continue” every time. Just say which way you want at the start. Reddit discussion
Codex has a Plan mode, and the command line has /plan. A good plan tells you what will change and how it’ll be checked. “Analyze, build, improve” is not a plan. OpenAI best practices
Don’t overdo it, though. Changing a button color doesn’t need a design doc. Reddit discussion
3. Point to the right files. Don’t dump everything.
Codex can search your files. But making it search from scratch every time wastes time.
When you give it a job, point to the files, pages, error messages, or examples that matter most. On a big project, ask it to list what it plans to read first. Don’t make it read everything before every small change. Reddit discussion
OpenAI said this plainly: fixing a typo shouldn’t mean reading all your setup and design docs first. Tell it where to look based on the job. OpenAI blog
Same goes for long output. If a test spits out thousands of lines, have it look at what failed first. Only dig deeper if needed. Huge reports flooding the chat don’t help fix anything. Reddit discussion
Not a programmer? Keep everything for one topic in one project folder. Then you can tell Codex “use the doc we already have” instead of explaining the background again. Riley Brown video, from 04:03
4. AGENTS.md, Skills, and plugins: what goes where
People mix these up a lot. Here’s the simple version:
| What you need | Put it here | Example |
|---|---|---|
| Rules this project always follows | AGENTS.md | Where files go, how to run it, how to check it |
| A way of doing one kind of task again and again | Skill | Weekly report, research a topic and write it up |
| Access to other apps | Plugin, connector, or MCP | Your email, calendar, or code platform |
MCP is just a standard way to plug Codex into other tools. Agent Engineering 101
AGENTS.md holds the few rules that always apply: key folders, how to start the project, how to check work. Codex looks for this file in specific places. Naming a random file RULES.md won’t work. OpenAI AGENTS.md docs
A Skill is for one task you do over and over. Say clearly when to use it. Having lots of Skills installed doesn’t mean every task needs all of them. OpenAI Skills docs
You’ll see people share rule files that are hundreds of lines long. Borrow ideas, but don’t copy the whole thing. Their project isn’t yours. And if a Skill isn’t showing up, check where it’s installed and what it’s called before making more copies. Reddit discussion
5. One chat, one goal
Don’t put everything into one never-ending chat. Writing an article, fixing a form, and planning next quarter are three different jobs, even in the same project.
But don’t start a new chat for every question either. Still working on the same problem? Stay in the same chat. Goal changed, or the old chat is getting confusing? Start fresh.
Handy command-line shortcuts:
| Command | What it does |
|---|---|
/resume | Go back to an old chat |
/fork | Keep this chat and try a different idea in a copy |
/compact | Shrink older messages into a summary to free up space |
/status | See your current settings and how much space is used |
The desktop app has its own buttons for this. One heads-up: copying a chat doesn’t copy your files into a safe separate space. Those are different things. OpenAI commands docs
Before switching chats on a long job, ask for a short handoff note. It works better than pasting old messages.
Write down the goal, what’s done and checked, what’s still broken, the files involved, and what’s next. If there’s already a progress file, update it instead of making a new one. Keep “confirmed” and “still guessing” separate.
A new chat doesn’t automatically remember everything from the last one. It has to go look. Tech With Tim video, from 28:39
And ignore rules like “always shrink the chat at 60%” or “always use the biggest memory setting.” They don’t fit everyone. Cut out stuff it doesn’t need first. Reddit discussion
6. For design changes, show it, then make it check
“This looks bad” tells Codex almost nothing. A screenshot, a circle around the problem, and what you want changed tell it a lot.
In this screenshot, the button in the top right is crowding the title. Fix the spacing so the title can wrap. Then open the page on desktop and phone sizes and click the button once to make sure it works.
You can point at exact parts of a page and ask for changes, then have Codex click through buttons and menus one by one to check. Tech With Tim video, from 17:20 · Riley Brown video, from 22:21
Remember: “the page opens” doesn’t mean the form works. “A file was made” doesn’t mean it’s right. And if the job needs a browser or control of your computer, make sure Codex actually has that access. Don’t assume it does. OpenAI prompting guide
7. “Done” needs proof, not just “fixed it”
When you check its work, ask three things:
- Is it right? Does it actually do what you asked? Do the numbers have sources?
- Did it change too much? Did it mess with things you didn’t ask about?
- Was the check real? Would the test actually catch this kind of mistake?
Here’s a common trap. A test checks “is the answer a number?” but not “is the refund amount correct?” Passing that test proves almost nothing. Reddit discussion
For code fixes, try:
First make the bug happen again so we know what’s wrong. Then fix just that. Run the checks that matter for this change, including the normal case and the tricky edge cases. Tell me what passed, what you couldn’t run, and what’s still unchecked.
If your project already has tests, run them before changing anything. That gives you a “before” picture. For small text or style tweaks, you don’t need to run every test every time. Simon Willison: First run the tests
Codex can help review code too. Ask it what the change touches, what the tests cover, and what’s still missing. Then double-check what it says. OpenAI code review docs
If it says “fixed” three times and the bug is still there, stop saying “try again.” Make it go back to the steps that cause the bug, the real error logs, and the current files. Keep changes small enough to read, and checks clear enough to give a yes or no. Reddit discussion
8. Want to save usage? Cut the redo first
OpenAI suggests starting with the default thinking level and only turning it up for hard planning or tricky problems. Higher levels can do better on tough jobs, but they’re slower and use more. OpenAI models docs
A simple rule:
- Easy stuff (rewording, formatting, small clear changes): use a faster model or the default level.
- Hard stuff (bugs across many files, big decisions, complex logic): use a stronger model or higher level.
Building a whole website and changing a font color are not the same job. Don’t pay the same price for both. Matthew Berman video, from 06:04
The biggest waste usually comes from three things:
- Making it guess the same thing over and over
- Making it re-read tons of files every time
- Feeding long logs back into the chat
Fix those first. Then see if you still need to switch models.
Also, be careful with “I got 3× more usage!” posts. In one of them, the main agent used less, but the total across all agents didn’t go down. That doesn’t mean you’ll save 3×. Reddit discussion
9. Running several jobs at once? Make sure they don’t edit the same files
Running jobs side by side works when they don’t overlap. One researches competitors, another sorts interviews, and a main job puts it all together. Each one needs to know what it’s doing and who combines the results. Hacker News discussion
If several jobs will change the same code, look into Git worktrees. In plain words: each job gets its own copy of the code, so they don’t overwrite each other. Your project needs to use Git, and each copy still needs its setup, plus a plan for combining the results later. OpenAI worktrees docs
Common mistakes:
- Checking folder A while the app is actually running from folder B
- A new copy missing things it needs to run
- Ending up with several results and no idea where to merge them
So before you start, decide which folder each job uses, who owns what, and where you’ll check the final result. Reddit discussion
Copying a chat, starting a new chat, and making a separate code copy are three different things. And for a small job, one agent doing it and checking it is usually easier than splitting it up.
10. Got a process that works? Save it as a Skill, then put it on a schedule
Say you often write articles about new topics. Your steps might be: pick a topic, read the official docs and what users say, grab video transcripts, then write. Do it for real a few times. Keep what works, fix what doesn’t.
The best time to make a Skill is right after you finish a real task and you’re happy with how it went. Riley Brown video, from 15:15
Turn the process we just used into a Skill. Write down what goes in, what comes out, what to check, and what to do when common things go wrong. Don’t lock in this topic, my account info, or any temporary file paths.
Once it runs smoothly, schedule it. For example: every week, check a folder for new files and write a summary. Say where to look, where to save the result, and when to let you know. Local jobs need your computer on and the app open. Web jobs can’t see folders on your computer. OpenAI scheduled tasks docs
The Skill decides how. The schedule decides when. If you’re still fixing the process every time, it’s not ready to run on its own yet.
11. Letting it run for a long time? Give it a clear finish line
For long jobs, you can set a goal. In the command line, /goal does this. The goal has to be something you can check. “Make it as good as possible” is not a goal. OpenAI commands docs
Make the approved changes on this list. Check each one. Fix anything your changes break. Stop when everything passes. If you’re missing a login or an important file, tell me exactly where you’re stuck. Don’t publish anything.
Want to limit time or usage? Use the settings the app actually has, and make sure they work. Typing “stop after three hours” in the chat is not a real timer.
Long runs can get a lot done, but they can also burn through a lot of usage. A clear goal and a clear stop point matter more than letting it run forever. Matthew Berman video, from 11:06
Try it today
Pick a small job you can judge yourself. Clean up an old article, fix one page problem, or make a comparison table from a few files. Don’t start with a giant project.
For example:
Turn the files in this folder into an article for beginners. First figure out which files are actually about the topic. Use official sources for facts, and keep personal opinions separate. Remove repeats. If two sources disagree, check before picking one. When you’re done, open the article and check the structure, sources, and that nothing contradicts itself. Give me the final file. Don’t change the original files.
When you look at the result, point out one specific thing. Like: “Paragraph three is too vague. Replace it with an example someone can actually follow.” Once it’s good enough, decide if it’s worth saving as a Skill.
You don’t have to be a programmer to work this way. Product managers, marketers, and researchers can use the same approach to sort out ideas and facts. Reddit discussion