The jobs I have given Codex worked when they shared three traits: clear boundaries, a way to check the result, and a way back if something went wrong. Here are seven real examples, in the order I ran into them, with no company figures and no customer information.

I do not always start Codex by hand. Often Claude Code sends it the task and then reviews what comes back; the split is described in Claude Code vs Codex. What follows is about what Codex did, and I mention the dispatching and checking only where it matters.

Case 1: a blog publishing script

I wanted to publish posts without editing web pages by hand: read a data file, generate the pages, and update the sitemap and the RSS feed. I asked Codex to design the data structure, write the publishing script and the RSS script, then work through the errors one by one. That is the foundation of this blog, and I described the process in OpenClaw + Codex.

It worked because the request was specific: Python, read JSON, parse the post, generate HTML, update the sitemap, handle errors. For the same job, a bare “write me some code to publish a blog” scatters the result much more. I compared the two ways of asking in that article.

Case 2: repairing a comment system

The comment API did not respond, the Nginx configuration was wrong and the Python service kept crashing. I asked Codex to read the error logs first, then fix the Python script, rewrite the Nginx configuration and create a systemd service so the program restarts itself after a crash.

At the time I split the job: restarting, checking the status, testing the endpoints and confirming that comments were really saved were done on the server by another tool. Codex only handled reading logs and editing code. That kept its boundary clear, and it ran nothing on my server.

Case 3: a lock that never released

At the end of May, the hourly product sync between two systems failed every time. The root cause: a sync process died halfway, the state stayed “running” forever, and every hourly job that saw the lock simply quit. It had been turned away 38 times in one day.

Claude Code found the cause first. Then I asked Codex to add three things: if nothing has happened for more than 30 minutes, treat the process as dead and take the lock back; write a “still alive” record regularly during long syncs; and move one preloading step into the error-handling block. Claude Code reviewed the change, deployed it after a backup, and confirmed that the next incremental sync ran to the end. A job whose cause is known and whose changes are listed is easy to hand over.

Case 4: putting the right brand on products

In July I checked the product data I send to Google Shopping and found that a large share of products had my own shop’s name as the “brand”, not the manufacturer’s, which risked rejection.

Codex wrote a brand-extraction patch: a dictionary of more than 60 brands, plus a rule against false positives, for instance an “iPhone case” must not be tagged as an Apple product. The patch was tried on a batch of sample products, and 10 trap samples I had set all passed, before it went live. Afterwards, far fewer products were missing a brand.

Case 5: an analytics snippet on several sites, and knowing when to stop

In early October I asked Codex to add a small visit-counting snippet to the pages of static websites. The rule was to compare every file with the live original and allow only that one extra block. For two of the sites, 11 pages in total, the procedure was: back up, edit, compare; the home page and two inner pages returned 200, the snippet appeared exactly once, every other byte was unchanged, and the rollback command was written down too.

On another site it did not touch anything: that site’s security policy only allows scripts from its own origin, so the browser would have blocked the snippet. Codex changed no file and put the reason in its report. A separate task with an explicitly written scope handled the same site: it added that one domain to the policy in the server configuration (two lines), then inserted the snippet in 10 pages, all returning 200.

Case 6: documentation research

Not every job is writing code. I am building a voice dictation tool for my own use. I asked Codex to read the official documentation of 14 representative products and systems and 5 kinds of speech-recognition platforms, then compare it with two similar programs installed on my computer, read-only, changing nothing. The result was a 376-line report that discusses the market and the design of my tool together.

The report supplies material, not decisions. Which ideas to use and which to drop is still for me to decide, after checking the sources myself.

Case 7: rehearse on a copy, stop at the threshold

My online shop needed prices that drop with the quantity bought. The conditions I gave Codex were: work only on a copy of the live shop, set several safety thresholds, and stop if one is not met. One version slowed the page and the add-to-cart step beyond the +10% ceiling I had set, measured between +24% and +27%. Another showed that saving a category in the back office triggered a hook that deleted cache entries.

Both times Codex did not push through: it restored the copy to its original state and handed in a report that said no, not a package marked “ready to deploy”. The live shop was only read, never written to. A later version passed and went live. For me, a result that stops and reports honestly is worth more than a bare “done”.

What they have in common

Not one of the seven was “optimise this for me”. Each one could say what to change, what not to change and what counts as finished.

  • Going live, deleting, paying and sending anything outside are not handed to it. I give the go-ahead.
  • In the isolated mode I use, it has no network by default and cannot commit code itself; only a task that needs the network says so on its first line.
  • Every time I require it to run its own checks (tests, comparisons, samples), and I spot-check afterwards.

To understand what it is first, read What Is Codex.