Codex app adds /goal for long-running React Doctor and iOS runs

• TheRealAdamG said /goal is now in the Codex app, not just the CLI, extending long-running runs from a terminal workflow into the desktop surface.
• reach_vb's launch post framed /goal around durable objectives with explicit end states, while OpenAI's follow-goals guide says the feature is meant for hours-long autonomous progress on one objective.
• In doodlestein's React Doctor run, Codex spent about 15 hours autonomously driving a React audit from a low score to 100, with typecheck, build, and headless browser validation recorded in the final evidence.
• kevinkern's iOS demo and mattlam_'s remote-control prototype showed the pattern spreading beyond refactors into app features, simulator-driven testing, and phone-linked control surfaces.
• reach_vb's expense report example and dkundel's weekend-planning workflow pushed /goal past coding into browser, Gmail, Drive, and Sheets tasks, which is where the harness starts to matter as much as the model.

You can read OpenAI's own follow-goals guide, watch community demos of direct Chrome use on macOS and Windows, and even trace the tmux-heavy orchestration ideas behind some of the more extreme multi-agent setups in doodlestein's linked NTM repo. The weird bit is how quickly the evidence jumped from migrations and refactors to reimbursements, MIDI chord trainers, and overnight iOS UI work, with jxnlco also noting that /goal has a set_goal() function under the hood.

OpenAI staff made the surface expansion explicit. TheRealAdamG said /goal is in the Codex app, and an earlier post from the same author pitched the feature as a model-plus-harness experience rather than a single prompt trick.

The official framing in OpenAI's guide matches that shift: use /goal for one durable objective, give Codex a clear stopping condition, and let it keep working for multiple hours. TheRealAdamG's doc link post surfaced the same wording in screenshot form, including the detail that the feature is meant for work with a validation loop, not ordinary one-turn prompting.

The core interaction pattern is persistence plus steering. In Dimillian's goal report screenshot, the active run keeps a structured checklist of rendering and gameplay milestones, while mattlam_ showed a run still pursuing a goal after more than a day.

That lines up with the control model in the docs and tweets:

• reach_vb described /goal as “tell it what done looks like,” then let it keep iterating until it hits that end state.
• Dimillian showed that you can keep asking questions and steering while the run is live.
• mattlam_ posted a seven-hour run, while the thread on mattlam_'s later screenshot put another run at roughly a day and a half.
• sound4movement reduced the user experience to a memeable loop: start /goal, go for a walk, come back to a cleared goal.

The cleanest concrete win came from React Doctor. doodlestein's post says a /goal run with react-doctor took a site from a low score to 100 in around 15 hours of fully autonomous work.

The attached audit log matters because it shows the validation chain, not just the claim. The run reportedly:

1. Read repo instructions and docs.
2. Inspected architecture with code investigation tooling.
3. Confirmed how react-doctor scans directories.
4. Reached a final React Doctor audit of 0 warnings, 0 errors, score 100.
5. Passed bun run typecheck.
6. Passed bunx next build.
7. Installed Playwright Chromium and visited the site headlessly.

That same React-doctor-plus-agent pattern was already spreading outside Codex. aidenybai's React Doctor Agent Skill launch advertised installable agent support a day earlier, and kevinkern's Chrome-controlled React Doctor screenshot argued that direct browser control is what makes these loops more trustworthy, because the agent can verify the rendered app instead of trusting a diff.

Several posts turned /goal into an overnight prototyping engine. kevinkern said he was using it all day to build, review, and auto-test a side iOS app by feeding feature requests, while his follow-up showed a helper that captures the iOS simulator inside Codex's in-app browser.

The mobile-adjacent experiments broke into two tracks:

• kevinkern used /goal for feature work plus auto-testing on an iOS side project.
• kevinkern's follow-up highlighted a serve-sim helper that streams the simulator into Codex.
• mattlam_ used /goal to build a remote-control command that starts a laptop server, generates a fresh token and QR code, and syncs a phone web app with the laptop session.
• mattlam_'s earlier remote-control post tied that prototype to a broader expectation of session continuation from local machine to remote control, and eventually to an iOS surface.

This is Christmas-come-early material for coding agent nerds because it shifts /goal from “long refactor mode” into “persistent UI workbench.” The evidence pool is full of people using the same mechanism for app UI cleanup, simulator inspection, and browser-mediated control rather than pure code generation.

The most revealing examples were not code at all. In reach_vb's reimbursement post, Codex handled invoices, a spreadsheet update, and form filling with Gmail, Drive, Sheets, and a Chrome extension in about 20 minutes.

According to reach_vb, the stack for that run was:

• Gmail plugin, for tracking invoices.
• Drive and Sheets plugin, for state tracking.
• Chrome extension, for the actual reimbursement form and uploads.

The browser piece is corroborated by the Chrome demo video, which describes Codex operating in the user's real Chrome profile across multiple tabs, and by sound4movement's linked YouTube post, which summarized the same macOS and Windows capability. dkundel then pushed the pattern into weekly planning: ingest sessions plus Slack and Gmail, suggest next-week work, then let /goal chew through it over the weekend.

A small but important implementation detail surfaced after the demos. jxnlco said /goal is not only a slash command, it also has a set_goal() function, and argued that prompting the model to write its own goal can outperform a user's first attempt.

That advice sits next to the most concrete operator guidance in the tweet pool:

• jasonzhou1993 said to use interview mode to align expectations.
• the same thread said to define clear stop conditions.
• that thread again suggested a “goal-buddy” pattern for constructing state and goal files.
• skirano described a loop where Codex creates a skill, tests it, grades it, and keeps improving it until a target threshold is met.

Those details make /goal look less like a hidden turbo button and more like a thin workflow primitive. The interesting move is not that Codex can keep running, it is that users are starting to wrap that persistence around explicit artifacts, validators, browser tools, and state files.