Getting the Most Out of Codex: Tools, Threads, and Automation (Bilingual Version)

*Getting the Most Out of Codex*

Source: OpenAI Codex Official Guide | English-Chinese Bilingual Edition

Most developers first use coding agents for code: inspect a repository, make a diff, run tests, and open a pull request. That's still the center of gravity for Codex. But much of the work on a computer is already mediated by code: executing shell commands, browsing web pages, calling APIs, exporting documents, responding to events, and triggering automations. As those surfaces become available to Codex, it starts to feel less like a coding assistant in the narrow sense and more like a system for getting computer work done.

Most developers first use coding agents for code: inspect a repository, generate a diff, run tests, and create a pull request. This remains Codex’s core use case. But a lot of computer work is already code-mediated: running shell commands, browsing web pages, calling APIs, exporting documents, responding to events, and triggering automations. As these capabilities become available in Codex, it increasingly stops feeling like a narrow coding assistant and starts to feel like a general-purpose system for getting computer tasks done.

The Codex app makes that shift concrete. A thread can keep context, use tools, surface artifacts, and continue across prompts instead of resetting after each exchange.

The Codex app makes this shift tangible. A thread can preserve context, use tools, present artifacts, and continue across prompts instead of resetting after each message.

Getting more out of Codex means using these capabilities together:

Getting the most out of Codex means applying these capabilities together:

• durable threads that preserve context
• voice, steering, and queuing while the user is still in the loop
• browser, computer-use, MCP servers, and connectors that let Codex act beyond a repo
• thread automations and Goals that continue the work while the user is away
• the side panel, where users can review code, documents, decks, and other artifacts

• durable threads that preserve context
• voice input, steering, and queueing while the user remains in control
• browser tools, computer-use, MCP servers, and connectors that allow Codex to work beyond the repository
• thread automations and Goals that continue work while the user is away
• the side panel, where users can review code, documents, decks, and other artifacts

1. Durable Threads / Durable Threads

Durable threads: Long-running Codex threads that preserve working context across repeated sessions.

Durable Threads: Long-running Codex threads that preserve working context across multiple sessions.

Pinned threads are one way to keep durable threads close at hand. They're useful for recurring work streams such as:

Pinned threads are one way to keep durable threads readily available. They are useful for recurring workflows such as:

• a Chief of Staff thread
• a release thread
• a documentation review thread
• a thread dedicated to external monitoring

• a chief-of-staff thread
• a release thread
• a documentation review thread
• a thread dedicated to external monitoring

These are persistent workspaces, not short chats. Codex can revisit them over time, preserving prior decisions, preferences, and working context that would otherwise need to be rebuilt from scratch.

These are persistent workspaces, not short-lived chats. Codex can revisit them over time while preserving prior decisions, preferences, and working context that would otherwise have to be reconstructed from scratch each time.

Pinned-thread shortcuts make this practical. Command-1 through Command-9 jump directly into saved threads.

Pinned-thread shortcuts make this practical. Command-1 through Command-9 jump directly into saved threads.

2. Voice Input

Voice input is valuable because it captures the rough version of a thought before it's compressed into polished prose.

Voice input is valuable because it captures the rough shape of a thought before it is polished into finished prose.

Codex has built-in voice input. It works especially well for vague starting points that are natural to say but awkward to type:

Codex includes built-in voice input. It works especially well for vague starting points that are natural to speak but awkward to type, such as:

I think someone named Ben mentioned this in Slack.

I do not remember the details.

Please go look.

I think someone named Ben mentioned this in Slack.

I don't remember the details.

Please go look into it.

For an agent that can search, gather context, and report back, that's often enough.

For an agent that can search, gather context, and report back, that is often sufficient.

It also works well for a two- or three-minute thought dump before the task is fully formed.

It is also useful for a two- to three-minute stream-of-thought before a task is fully formed.

Transcripts work the same way. A raw meeting transcript or dictated planning note often provides better source material than a short summary because it preserves uncertainty, emphasis, and unfinished lines of thought.

Transcripts work similarly. A raw meeting transcript or dictated planning note often provides better source material than a short summary because it preserves uncertainty, emphasis, and incomplete lines of thought.

3. Steering and Queuing

Voice becomes even more useful when paired with explicit control over an active task.

Voice becomes even more useful when paired with explicit control over an active task.

Steering: Interrupting an in-flight Codex task with new direction before the current step finishes.

Steering: Interrupting an in-flight Codex task with a new direction before the current step finishes.

Steering is useful when the agent is heading the wrong way and needs a correction before it finishes. During a website review, for example, the user can interrupt the work while annotating the surface in the side panel:

Steering is useful when the agent is going in the wrong direction and needs correction before it completes. For example, during a website review, a user can interrupt the task while annotating the surface in the side panel:

make this smaller

the spacing between these two elements feels off

this copy is wrong

Make this smaller.

The spacing between these two elements feels off.

This wording is wrong.

Queuing: Adding work for Codex to do after the current step completes.

Queuing: Adding work for Codex to do after the current step is complete.

Queuing is different. It doesn't interrupt the task in progress. It adds the next task to the line. A user might say:

Queuing is different. It does not interrupt the task in progress; it adds the next task to the queue. A user might say:

Once the work is done, send the preview link to the reviewer in Slack.

Once the work is finished, send the preview link to the reviewer in Slack.

Steering changes what Codex is doing now. Queuing changes what should happen next. Both keep the user close to the work while it's unfolding.

Steering changes what Codex is doing now. Queuing changes what should happen next. Both keep the user close to the work as it unfolds.

4. Tools and Reach

Once a thread has continuity, the next question is what it can act on. Codex can move outward in layers:

Once a thread has continuity, the next question is what it can act on. Codex can expand outward in layers:

• $browser for the in-app browser in the side panel, where Codex can inspect and annotate web surfaces
• @chrome for signed-in browser state and Chrome-based workflows
• @computer for work that only exists through a desktop GUI

• $browser for the in-app browser in the side panel, where Codex can inspect and annotate web surfaces
• @chrome for workflows that depend on a signed-in Chrome browser state
• @computer for work that exists only in a desktop GUI

$browser fits side-panel browser review. @chrome fits signed-in browser work that depends on the user's Chrome context. @computer fits tasks that only exist through a desktop GUI.

$browser is for side-panel browser reviews. @chrome is for signed-in browser tasks that rely on the user's Chrome context. @computer is for tasks that exist only through a desktop GUI.

MCP servers and connectors extend the same idea into the rest of a workflow. Slack, Gmail, and Calendar matter because many important tasks first appear as messages, inbox items, or scheduling problems before they ever become code.

MCP servers and connectors extend this same idea across the rest of the workflow. Slack, Gmail, and Calendar are important because many critical tasks first appear as messages, inbox items, or scheduling issues before they ever become code.

Skills make repeated workflows reusable. Once a workflow proves useful, package it as a skill so Codex can run it again without relearning the routine from scratch.

Skills make repetitive workflows reusable. Once a workflow proves useful, package it as a skill so Codex can run it again without having to relearn the routine from scratch.

5. Work from Anywhere

The Codex mobile app changes when the user has to be at the desk. A task can start on a Mac where the files, permissions, and local setup already live, then continue while the user checks in from a phone.

The Codex mobile app changes the assumption that users must be at a desk. A task can begin on a Mac, where files, permissions, and local setup already exist, and then continue when the user checks in from a phone.

That matters in small moments. Someone can leave the desk while Codex runs a longer task, answer a question from outside, approve the next step, or redirect the thread before they get back. The local environment stays in place; the user doesn't have to.

That matters in small windows of time. A person can leave the desk while Codex runs a longer task, answer a question remotely, approve the next step, or redirect the thread before returning. The local environment stays in place, so the user does not have to set it up again.

6. Automations

Automations run Codex work on a schedule. Use a scheduled automation when the recurring job should start fresh from a workspace, such as a daily report or a regular repository check. Use a thread automation when the schedule should return to an active conversation with its running context.

Automations make Codex run work on a schedule. Use scheduled automations when recurring work should start fresh from a workspace, such as a daily report or regular repository check. Use thread automations when the schedule should return to an active conversation with running context.

Thread automations: Heartbeat-style recurring wake-up calls that return to the same Codex thread on a schedule.

Thread automations: Heartbeat-style recurring wake-up calls that return to the same Codex thread on a schedule.

Pinned threads are useful, but they still wait for the user to return. A thread automation can check on something every few minutes or every few hours, continue until it meets a condition, and adjust the cadence over time.

Pinned threads are useful, but they still wait for the user to come back. A thread automation can check on something every few minutes or hours, continue until a condition is met, and adjust the cadence over time.

A Chief of Staff thread might run every 30 minutes:

A Chief-of-Staff thread might run every 30 minutes:

Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention.

Help me prioritize what matters most.

If someone asks me a question, research the answer as deeply as you can and draft a reply for me, but do not send it.

Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention.

Help me prioritize what is most important.

If someone asks me a question, research the answer as deeply as possible and draft a reply for me, but do not send it.

When the user returns, the expensive part of gathering context is often done. The human still decides what gets sent.

When the user returns, the expensive part of context gathering is often already complete. The human still decides what gets sent.

Thread automations also fit feedback loops. A thread automation can watch pull request comments, Google Docs comments, or Slack replies and keep the surrounding work moving while the user is away.

Thread automations also work well for feedback loops. A thread automation can watch pull request comments, Google Docs comments, or Slack replies and keep related work moving while the user is away.

Consider an animation workflow where a reviewer shares a video in Slack. A thread automation can check the thread on a schedule, render an updated version when comments arrive, and reply in the same thread tagging the reviewer. If one integration can't complete the final upload, desktop automation can finish the step through the GUI.

Consider an animation workflow where a reviewer shares a video in Slack. A thread automation can check the thread on a schedule, render an updated version when comments arrive, and reply in the same thread by tagging the reviewer. If one integration cannot complete the final upload, desktop automation can finish the step through the GUI.

The loop spans Slack for feedback, the codebase for rendering, and desktop automation for the final upload.

The loop spans Slack for feedback, the codebase for rendering, and desktop automation for final upload.

7. Goals

Goals are most powerful when the task has a real finish line that the agent can keep pushing toward. A weak goal is:

Goals are most powerful when the task has a true finish line the agent can keep pushing toward. A weak goal is:

Goals: Longer-running Codex tasks with a finish line the agent can keep working toward over time.

Goals: Long-running Codex tasks with a finish line that the agent can continually work toward over time.

Implement the plan in this Markdown file.

Implement the plan in this Markdown file.

A stronger goal has a measurable success criterion.

A stronger goal has a measurable success criterion.

For example, an engineer might migrate an internal tool from Python to Rust by setting up the new directory, defining the goal, and making the finish line explicit: the new implementation isn't done until the unit tests pass.

For example, an engineer can migrate an internal tool from Python to Rust by creating a new directory, defining the goal, and making the finish line explicit: the new implementation is not complete until the unit tests pass.

A goal combines ongoing execution with a verifier. The user defines the outcome, the stopping condition, and the signal that says whether Codex is getting closer.

A goal combines ongoing execution with a verifier. The user defines the outcome, stop condition, and the signal that indicates whether Codex is getting closer.

Useful verifiers include:

Useful verifiers include:

• a test suite
• a benchmark
• a bug reproduction
• a validation matrix
• an end-to-end workflow that must keep passing

• a test suite
• a benchmark
• a bug reproduction
• a validation matrix
• an end-to-end workflow that must keep passing continuously

Ambition matters, but without verification it's just a wish.

Ambition matters, but without verification it is just wishful thinking.

8. The Side Panel

The side panel keeps the work beside the conversation that produced it. Instead of exporting an artifact and switching contexts, the user can review it in place. The output might be code, but it might also be a deck, a PDF, a browser page, a table, or another artifact created along the way.

The side panel keeps work beside the conversation that produced it. Instead of exporting an artifact and switching contexts, users can review it in place. The output can be code, but it can also be a deck, PDF, web page, table, or another artifact created along the way.

It supports four jobs especially well:

It is especially good at four tasks:

• Inspect artifacts
• Annotate what needs to change
• Operate web surfaces
• Review changes

• Inspecting artifacts
• Marking what needs to change
• Operating web surfaces
• Reviewing changes

The side panel lets users review Markdown, spreadsheets, data tables, documents, and slides in place. They can inspect, mark up, and revise artifacts without breaking the loop.

The side panel lets users review Markdown, spreadsheets, data tables, documents, and slides in place. They can inspect, annotate, and revise artifacts without breaking the loop.

Annotations

The deck or PDF can stay open beside the thread that produced it, ready for direct review and repair.

The deck or PDF can remain open next to the thread that produced it, ready for direct review and fixes.

Sheets in Codex

The in-app browser lets Codex inspect a rendered page, control it, and respond to annotations directly on the surface under review. Comments on a page or artifact stay inside the working loop instead of becoming a separate handoff.

The in-app browser lets Codex inspect a rendered page, control it, and respond directly to annotations on the surface under review. Comments on a page or artifact stay in the working loop instead of becoming a separate handoff.

The web becomes both output and control surface. Codex can build an artifact, open it in the side panel, inspect it, debug it, and keep refining the same object in place.

The web serves as both output and a control surface. Codex can build an artifact, open it in the side panel, inspect it, debug it, and keep refining the same object in place.

These surfaces work especially well:

These surfaces work especially well:

• index.html for lightweight static artifacts
• Storybook for UI review
• Remotion Studio for programmatic animation
• browser-based slide decks for presentations
• data apps for analysis workflows

• index.html for lightweight static artifacts
• Storybook for UI reviews
• Remotion Studio for programmatic animation
• browser-based slide decks for presentations
• data apps for analysis workflows

A single index.html file can become a durable interactive artifact with no server required. Thread automations can also refresh static artifacts over time so a thread has something new waiting when the user returns.

A single index.html file can become a durable interactive artifact without needing a server. Thread automations can also refresh static artifacts over time so that when the user returns, the thread has something new ready for review.

9. Shared Memory

Long-running threads become more useful when they share memory outside any one conversation.

Long-running threads become more useful when they can share memory beyond any single conversation.

Shared memory: Durable context stored outside a single thread so future work can resume from something explicit and reviewable.

Shared memory: Durable context stored outside a single thread so future work can resume from explicit, reviewable material.

One durable pattern is to anchor persistent threads in an Obsidian vault. In practice, that means a folder of plain files that stays straightforward to inspect, edit, move, and keep for a long time. Teams can store that folder in cloud storage, Git, Dropbox, Google Drive, or another sync layer that fits their workflow.

One durable pattern is anchoring persistent threads in an Obsidian vault. In practice, this is a folder of plain files that remains straightforward to inspect, edit, move, and keep over the long term. Teams can store that folder in cloud storage, Git, Dropbox, Google Drive, or any sync layer that fits their workflow.

A vault might look like this:

A vault might look like this:

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

At the top level, AGENTS.md can define how Codex should update that workspace as it learns more about people, projects, decisions, and open loops.

At the top level, AGENTS.md can define how Codex should update that workspace as it learns more about people, projects, decisions, and open loops.

Don't copy one exact vault structure. Teach the agent where durable context should live, what context to preserve, and when not to create churn.

Do not copy a single fixed vault structure. Teach the agent where durable context should live, what context should be preserved, and when not to generate churn.

A practical AGENTS.md might say:

A practical AGENTS.md might say:

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

Repositories hold code. The vault holds rolling context: the people involved, what changed, what's blocked, what needs follow-up, and what would otherwise disappear between sessions.

The repository holds code. The vault holds rolling context: the people involved, what changed, what is blocked, what needs follow-up, and what would otherwise disappear between sessions.

Important context shouldn't live only inside a conversation transcript. Write it down somewhere the next thread can pick back up.

Important context should not live only inside a conversation transcript. Write it down somewhere the next thread can pick up.

Codex also has first-party memory features in Settings > Personalization > Memories. They provide a local recall layer for preferences, recurring workflows, and known pitfalls. They complement explicit written context rather than replacing it. Chronicle pushes in the same direction by helping Codex build memory from recent screen context.

Codex also has first-party memory features in Settings > Personalization > Memories. They provide a local recall layer for preferences, recurring workflows, and known pitfalls. They complement explicit written context rather than replacing it. Chronicle also goes in this direction by helping Codex build memory from recent screen context.

10. From Code Outward

Codex still starts from code. But more of the work around code is now reachable through the same system: MCP servers, browser surfaces, desktop controls, thread automations, and reviewable artifacts.

Codex still starts from code. But more work around code is now reachable through the same system: MCP servers, browser surfaces, desktop controls, thread automations, and reviewable artifacts.

That changes the control model. Steering interrupts the work in progress. Queuing lines up the next task. Thread automations keep a thread active when the user steps away. Goals add a concrete finish line that Codex can keep working toward.

That changes the control model. Steering interrupts work in progress. Queuing schedules the next task. Thread automations keep a thread active when the user steps away. Goals add a concrete finish line that Codex can keep working toward.

Codex can now carry a workflow from instruction to execution to artifact review, even when the work leaves the repo.

Codex can now carry a workflow from instruction to execution to artifact review, even when the work has moved beyond the repository.

*This article is based on the OpenAI Codex official guide. The English-Chinese comparison version was organized and translated by Lamjin.*

If you need a stable way to register and verify Codex from mainland China, you can refer to the giffgaff UK physical-number guide. For OpenRouter free models as a baseline for experimenting with Codex alternatives, see Recommended Free Models on OpenRouter.

Frequently Asked Questions

What's the difference between Codex and Claude Code?

Codex is OpenAI’s coding agent product, while Claude Code is Anthropic’s counterpart. Their design philosophies are similar (agents execute tasks in real environments), but their ecosystems and integration patterns are different. Codex focuses on GitHub integration and cloud execution, while Claude Code is more oriented toward local CLI workflows.

What is Codex’s "Durable Threads"?

Durable threads let Codex retain context across multiple prompt exchanges, so it does not reset each time. They are suitable for complex multi-step tasks that require progressive advancement. Combined with queuing and thread automations, Codex can continue with follow-up work while the user is away.

How do Codex Automations work?

Automations allow Codex to continue executing tasks while the user is offline (such as periodic repository checks, event response, and running tests), effectively turning Codex into a background worker thread. Goals let Codex keep pushing toward a concrete objective instead of waiting for manual triggers each time.

What external tool connections does Codex support?

Codex currently supports the browser, MCP servers, and various Connectors, enabling it to call external APIs, read and write documents, execute shell commands, and operate outside the codebase.

References

• Getting the Most Out of Codex (Original post)