How OpenAI's Top Codex Developers Use Codex

This is the kind of Codex task that makes a remote Mac feel less like a shell and more like a lab. Thomas Ricouard gave Codex a brutal target: make a one-to-one Swift port of the original Doom C engine. Codex did not stop at translating files. It started looking for ways to prove the port was actually equivalent.

For audio, Codex played the Doom music through the Mac speakers loudly enough to wake Thomas up, recorded the output, and compared the result against what the engine should produce. For graphics, it ran the C engine and the Swift engine frame by frame, captured pixels, and built comparison tooling to hunt down mismatches.

That is the capability worth copying. If you ask Codex to rewrite a renderer, migrate a native app, or port a CLI from one language to another, do not just ask for code. Ask Codex to build the parity harness: fixture inputs, side-by-side runners, screenshots, audio captures, checksums, logs, and a final mismatch report.

Prompt shape:
Port this engine from C to Swift.
Before calling it done, create a parity harness.
Run old and new implementations against the same inputs.
Capture frames, audio, logs, or checksums.
Fix mismatches until the harness passes or explain exactly what remains different.

The killer /goal story is not that Codex can fix one bug. Romain Huet talked about someone pointing Codex at a Linear backlog of roughly 75 bugs, going to bed, and waking up to the backlog cleared. That is the mental shift: the unit of work becomes an outcome, not a ticket.

OpenAI describes /goal as a durable objective for long-running work, with controls to inspect status, pause, resume, and clear the goal. In practice, the best /goal prompts read like a work order: target state, scope, stop condition, commands that prove progress, and the handoff you expect when Codex is done.

/goal
Clear the Linear view "May cleanup" of all reproducible P0/P1 bugs.
Read the issue list, failing logs, repo docs, and test scripts first.
Group related failures into checkpoints.
For every fixed issue, add or run a regression test.
Report: issue id, fix summary, command run, result, remaining risk.
Stop if a product decision, missing credential, or unreproducible bug blocks progress.

This is exactly where a remote Mac mini earns its keep. Codex can keep the repo hot, leave tests running, preserve browser and Linear sessions, checkpoint changes, and continue for hours without depending on your laptop staying awake.

VB gave Codex a one-line /goal: rebuild the full Codex app changelog from the beginning of the product. The repo had thousands of commits. Some were experiments. Some were behind feature flags. Some were actual generally available changes that belonged on the developer site.

Codex worked for roughly 10 hours, walked the commit history, separated experimental flags from shipped behavior, and produced changelog entries for every app release. That is a fantastic remote-Mac task because the machine can keep the repo checked out, run git queries all day, inspect release tags, and hold the working draft until a human edits the final prose.

1. Give Codex one excellent example changelog entry so it can match the style.
2. Ask for a candidate table first: commit, release, product area, user-facing impact, confidence.
3. Make it label each candidate as shipped, experimental, internal, refactor, or unclear.
4. Only after the evidence table looks right should Codex write the public changelog.

Brent Schooley was working on Premiere Pro plugins, where the hard part is not one button. It is the enormous editing surface: cuts, clip movement, timeline operations, SDK features, and ExtendScript DOM APIs. Codex can read the current plugin, compare it to what Premiere exposes, and figure out what the plugin should learn next.

The workflow is two goals back to back. First: audit the plugin, identify missing capabilities, prioritize them, and create a GitHub roadmap with child issues. Second: once the roadmap looks right, have Codex implement it. Brent had Codex spend about seven hours churning through that feature-gap roadmap.

This is a perfect remote Mac workflow because creative plugins often need the actual desktop environment: SDK docs, local builds, sample projects, app state, plugin bundles, and visual checks. Codex can keep all of that open while it scopes, patches, tests, and hands you a reviewable roadmap.

The teleprompter story is the best example of personal software suddenly becoming worth building. Dominic on the team wanted a better teleprompter for a video shoot. Off-the-shelf software did not match the exact workflow. So he gave Codex a brain dump and used Thomas Ricouard's macOS app-building plugin.

Seven minutes later, Codex had built the app he wanted well enough to use for the shoot. The point is not that teleprompters are complicated. The point is that Codex collapses the cost of tiny custom utilities: paste script, choose scroll speed, mirror text, adjust font size, enter fullscreen, and keep the controls out of the recording frame.

A remote Mac mini makes this smoother because Codex can build and run the native app where the macOS tooling lives, show the UI over VNC, capture a screenshot, and iterate on the exact workflow instead of pretending a mockup is the app.

A Codex user wanted to join a live X audio Space but could not tune in. So they asked ChatGPT to have Codex use a browser skill, join the live page, and record the audio for them. Codex did exactly that. This is the important part: many valuable events still happen in human-only interfaces, from livestreams and webinars to demos, customer calls, office hours, and replays.

The playbook is simple: give Codex the URL, expected duration, recording destination, and verification rule. It should confirm that playback is live, the timer is moving, the audio file is growing, or a waveform is present. After the event, it can download or save the audio, run transcription, diarize speakers, summarize decisions, and link timestamps back to the recording.

The remote Mac is the capture box. It can keep the browser logged in, preserve the page state, use whatever audio-recording setup you configure, and keep running after you walk away.

VB runs a large Codex ambassadors program across regions and time zones. That means DMs, Slack channels, Gmail threads, feedback, event logistics, and long discussions where consensus slowly forms. His heartbeat workflow asks Codex to check those surfaces every couple of hours and surface only what needs attention.

The important detail is memory across passes. Codex should not summarize Slack from scratch every time. It should compare this pass against the last one, identify what changed, mark what already got reported, and produce a short attention brief: urgent, waiting on me, decisions reached, FYI, and ignored noise.

Heartbeat prompt:
Every two hours, check Slack and Gmail.
Surface anything I should answer in the next five minutes.
Track long consensus threads and report only meaningful changes.
Do not repeat items from the previous heartbeat unless the state changed.
Draft replies only when my prior messages make the response obvious.

One underrated Codex workflow is pairing GPT image generation with frontend implementation. Generate a strong visual reference first. Then give Codex the image and ask it to build the actual app screen that matches the density, hierarchy, layout, color, and interaction states.

The loop is reference, implementation, screenshot, critique, fix. On a remote Mac mini, Codex can run the dev server, open the page, capture desktop and mobile screenshots, compare the result against the reference, and keep tightening spacing and typography until the UI actually lands.

1. Use image generation for a concrete product surface, not abstract mood art.
2. Ask Codex to name the layout primitives before it writes components.
3. Make it screenshot the local app at mobile and desktop widths.
4. Judge the screenshot, then ask Codex to fix the visual mismatches.

What Codex workflows does the article cover?

It covers real Codex workflows including a Doom C-to-Swift port, overnight backlog cleanup with /goal, changelog archaeology, Premiere plugin work, browser recording, teleprompter building, Slack triage, and recurring heartbeat automations.

Why do these Codex workflows benefit from a persistent Mac?

They need a stable machine with repo state, browser sessions, desktop apps, audio, screenshots, logs, credentials, and long-running processes that survive after a laptop sleeps or disconnects.