OpenAI Codex at the end of 2026: goal mode, dots and how to lock it down

I use Codex next to Claude Code in my own work, and it changed more this year than any other tool on my desk. It is part of the paid ChatGPT plans, it can chase a goal for hours, since September there are dots, always-on agents with their own cloud computer, and a cheaper model arrived at the end of October. That is a lot of autonomy to hand to a team at once. Most of the risk doesn't come from the model but from defaults nobody looked at: a sandbox that is wider than needed, approvals switched off on a laptop with production access. This is what is worth using today, and the exact settings I put in place before a team starts.

Dominik Heinrich

November 7, 202610 min read

1. Where Codex runs and what it costs

Codex is no longer a separate product you buy. OpenAI's pricing page lists it inside the ChatGPT plans: Plus at 20 dollars a month for 'a few focused coding sessions each week', Pro from 100 dollars with tiers at 100, 200 and 500, and Business at 20 dollars per user per month billed annually (25 monthly) with a dedicated workspace, admin controls, SAML SSO and no training on business data by default. Enterprise and Edu are priced on request. It runs in the ChatGPT desktop app, the Codex CLI, the IDE extension, on iOS and as cloud tasks that work on a copy of your repository, and ChatGPT Work and Codex share the same usage and credits. For CI there is a separate route: Codex with an API key, billed at API rates and without the cloud features such as GitHub code review. For a team pilot I usually start with Business, because the admin controls in the next steps only exist there.

2. The models underneath: Sol, Terra and the retired GPT-5.5

OpenAI released GPT-6.1 Terra on 26 October and made it available to Plus, Pro, Enterprise and Edu users in ChatGPT Work and Codex. In its announcement OpenAI states that Terra's standard API prices are 50% lower than those of GPT-5.6 Terra and GPT-6.1 Sol, at 1 dollar per million input tokens and 5 dollars per million output tokens. For long agent runs that matters more than a few benchmark points, because the cost per task decides how often you can afford to let an agent iterate. At the same time GPT-5.5 was retired from Codex with ChatGPT sign-in on 14 October; sessions authenticated with an API key weren't affected. My rule in projects: the cheaper model for high-volume, well-tested work such as dependency bumps and test fixes, the strongest model for refactors that cross many modules. Pin the model in config.toml for CI so a default change never surprises you mid-sprint.

Introducing dots, always-on agents built to handle everything, OpenAI (YouTube). Loads from YouTube only after you click.

3. Goal mode: a persistent target

Goal mode started as an experimental slash command in the CLI in spring and has been generally available across the app, the IDE extension and the CLI since May. The developer commands reference describes it simply: /goal followed by the objective sets it, /goal on its own shows it, and /goal edit, pause, resume and clear manage it while the task runs. Objectives can be up to 4,000 characters; for longer instructions, the docs suggest putting the details in a file and pointing the goal at it. The same rule applies as with any agent loop: write a finish line that commands can prove, not a wish. 'Finish the migration and keep tests green' is the docs' own example, and I tighten it further with the exact test command, the files that must not change and a stop clause. A goal that can't be verified doesn't end, it just gets expensive.

text

/goal Migrate src/payments from the v1 client to the v2 client.
Done when: "npm test -- payments" exits 0, "npm run typecheck" exits 0,
no file under src/legacy or test/fixtures is changed, and no test is skipped.
Work on a branch and summarise the diff when done.
If blocked for more than 3 attempts on the same error, stop and explain.

4. Dots: always-on agents that delegate to Codex

OpenAI introduced dots on 29 September at DevDay. A dot is an always-on agent with its own cloud computer and browser that keeps working when your laptop is off, connects to more than 4,000 apps through plugins and can be reached in ChatGPT, Slack and Teams, including by voice call. The part that matters for engineering teams is in OpenAI's dots documentation: a dot can create Work or Codex tasks, continue existing local Codex tasks and use a Codex cloud environment you've created for repository work. OpenAI's own example is a dot that watches customer feedback, scopes small fixes, builds and tests them and brings you complete pull requests with videos of the change. Your own computer stays separate unless you connect it, Custom Rules let you allow, require approval for or block specific actions, and an auto-review step checks risky actions against your instructions. Availability is uneven: Pro 100, 200 and 500 are not available in the EEA, the UK and Switzerland, while Business Premium is available in supported ChatGPT regions, and on 3 November OpenAI added GPT-6.1 Terra to the models behind dots.

Tip from practice

Conversations with your dot don't count towards ChatGPT usage limits, but tasks it starts in Codex or Work do. Watch usage in the first weeks, especially if a dot opens many small pull requests on its own.

5. Sandbox and approvals: pick the setting by risk

The sandbox docs describe two separate controls. The sandbox is the technical boundary for every command Codex spawns, including git, package managers and test runners: read-only lets it inspect files but not edit or run commands without approval, workspace-write lets it edit inside the workspace and run routine commands there, and danger-full-access removes filesystem and network boundaries. The approval policy decides when Codex stops and asks before crossing that boundary: on-request asks when it needs to go beyond the sandbox, never doesn't ask. 'untrusted' is no longer a supported approval policy and 'on-failure' is deprecated, so check old configs. My recommendation by risk: exploring an unknown repository, read-only with on-request. Normal feature work on a branch, workspace-write with on-request and network access off, which the docs call the lower-risk local automation preset. Unattended runs in a disposable container without secrets, workspace-write with never; the docs stress that 'never' only stops the prompts, it doesn't grant unrestricted execution. danger-full-access with never belongs only in a throwaway VM, never on a laptop that can reach production.

toml

# ~/.codex/config.toml (or .codex/config.toml in a trusted project)
# Everyday feature work: edits inside the workspace, asks before anything beyond it.
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"   # or "auto_review" to let the reviewer agent handle eligible prompts

[sandbox_workspace_write]
network_access = false        # turn on only for tasks that really need the internet

Tip from practice

When an approval prompt offers 'once' or 'for this session', pick the narrowest scope that lets the task continue, and use separate worktrees instead of widening access across repositories.

Interactive

Which Codex settings fit your task?

Pick the situation. You get the sandbox mode, the approval policy and the config to copy, using the setting names from the Codex docs (November 2026).

workspace-write

sandbox_mode

on-request

approval_policy

The docs' lower-risk automation preset: edits inside the workspace, asks before anything else.

# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

All calculators and checklists

6. Admin guardrails: requirements.toml

Personal config.toml files are preferences; users can change them. On Business and Enterprise, the managed configuration docs give admins a second layer. Under Agent security you edit policy guardrails, or the equivalent requirements.toml, which constrains security-sensitive settings: approval policy, approvals reviewer, sandbox mode, permission profiles, web search mode, managed hooks and which MCP servers and plugin marketplaces users can enable. Requirements limit the choices; separate defaults set the starting value. The docs' own example blocks '--ask-for-approval never' and '--sandbox danger-full-access', including the --yolo shortcut, by allowing only the safer values. Two details from the docs worth knowing: for Codex 0.138 and later, OpenAI prefers permission profiles with allowed_permission_profiles over the legacy allowed_sandbox_modes, and allowed_web_search_modes = ['cached'] prevents live web search even in full-access sessions. Leaving a requirement unset means no limit, so write down every key you rely on.

toml

# requirements.toml (Agent security > Edit as TOML), enforced for the workspace
# Users can still choose between these values, but nothing wider.
allowed_approval_policies = ["on-request"]                 # no "never" on managed devices
allowed_sandbox_modes     = ["read-only", "workspace-write"] # blocks danger-full-access and --yolo
allowed_web_search_modes  = ["cached"]                     # no live web search from agents

7. AGENTS.md, rules and the review gate

AGENTS.md is where conventions live: how to run the tests, which folders are generated, the architecture rules a reviewer would otherwise repeat. It is useful, but it is guidance, not a security boundary, and anything in the repository can change it, so review changes to it like code and give the platform team ownership of the file. For real exceptions, Codex has rules that allow, prompt for or forbid specific command prefixes outside the sandbox, which the sandbox docs recommend over broadly widening access. Project-level .codex/config.toml files only load once you trust the project, so a cloned repository can't quietly loosen your settings. The last layer is boring and essential: Codex works on a branch, CI runs the same checks as for a human, and a person approves the merge. Codex code review in GitHub is a good second reader, but it doesn't replace the human approval your branch protection requires.

8. How I roll it out in a team

Week one: Business workspace, SSO, requirements.toml with on-request only and no full access, and a short AGENTS.md per repository with the test and lint commands. Week two: five volunteers use Codex locally in workspace-write on real tickets, and we collect every approval prompt they found annoying; most of them become rules or writable roots instead of wider sandboxes. Weeks three and four: goal mode for well-tested work such as dependency upgrades and test repairs, plus cloud tasks for small issues, with the same CI and review as human changes. Dots come last, and only for a named owner with Custom Rules, because a dot that opens pull requests on its own needs someone who reads them. We measure lead time, review effort and cost per merged change. The pattern is the same as with every agent: guardrails first, then speed.

Takeaway
Codex is strongest with a verifiable goal, a narrow sandbox and dots that hand work to it, but set the guardrails centrally first and give people the speed second.

Real projects behind this

Try it yourself

Codex safety settings

Want this in your company? Let's talk mail@dominikheinrich.ch

Sources and official guides