Codex

Operator Read

Codex is OpenAI's bet on a stateful agent control plane, not a terminal prompt. Goals, sessions, threads, memory, plugin sets, permission profiles, sandboxes, and authority posture are all becoming first-class persistent state — and as of the 2026-05-21 product launch (26.519 + CLI 0.133.0), goal mode reaches a stable, default-exposed persistent-objective baseline: it graduates out of experimental, ships with dedicated storage and progress tracking, and turns on by default across app, IDE, and CLI. The default-on move and a second piece — permission profile inheritance plus a managed requirements.toml enforcement file — shipped together in the same release bundle. They are operationally complementary, not causally chained: the policy substrate is real policy substrate, but the framing that goal-default-on required it is softer than the release notes literally claim. Watch Codex as one large vendor's directional read on where closed-source coding agents go — directional, not predictive.

Run Codex Differently

Use /goal as a persistent objective, not a prompt extension. TUI-side validation handles paste, queued goal commands, length limits, and explicit operator guidance for longer instructions. The goal lifecycle is instrumented — goals are observable durable objects, not chat-local state.

Treat each session as identified runtime state, not ambient context. Sessions carry a session id through the runtime, making "which session is this" answerable; MCP turns carry thread metadata linking tool calls back to the conversational thread they belong to. Memory itself runs as a spawned MCP rather than being bolted into the agent — memory is a swap-able surface, not a fixed component.

If your hook layer rewrote tool inputs by returning updatedInput but the agent kept using the original, you have a behavior shift to verify. PreToolUse hooks now apply updatedInput rewrites before tool dispatch when the hook also returns permissionDecision: "allow". Hook authors can now sanitize, normalize, or redirect tool arguments before execution — the hook surface is no longer just allow/deny.

Authority Made Visible

The TUI status line carries permissions and approval-mode as separately configurable items. Authority that used to live behind /permissions and /status now sits in peripheral vision. Standard states render compactly (Read Only, Workspace, Full Access); user-defined permission profile names are preserved; non-standard shapes render as Custom permissions. Add both to your status line if you run more than one permission profile.

Plugin sharing has matured into a governance surface, not just a feature. Share carries explicit access controls separated from raw permissions. Share-context APIs are role-aware — "who can see this plugin" is a first-class question, not a binary access flag — and share settings have discoverability work on top of the role-aware context.

Platform Surfaces

A bundled Linux sandbox ships with Codex, removing the host-dependent sandbox setup step Linux operators used to maintain. The skills watcher runs in the app-server, consolidating skills management with the broader app-server direction the repo has been pursuing. Each of these refines a previously coarse property (implicit host sandbox setup, scattered skills management) into structured runtime state.

Goal Mode And Versioned Policy

Goal mode is no longer a research preview. The 26.519 product launch graduates it across app, IDE extension, and CLI; CLI 0.133.0 turns goals on by default with dedicated storage and progress tracking across active turns. Operators can point Codex at an objective spanning "hours or even days" without the prior opt-in ceremony. The same launch ships remote computer use after Mac lock as a new opt-in authority surface. The locked-host boundary is the load-bearing piece: the host's lock state is normally a hard signal that no agent should be operating; this feature lets that signal be overridden, with documented safeguards — short-lived authorization, scoping to active trusted computer-use turns, covered displays, relock on local input, manual-unlock fallback, and per-task enable. The capability is narrow and opt-in, not a default category event. The operator-facing rule of thumb: default-deny locked-host computer use for sensitive hosts and allow only scoped task classes after verifying stop/relock and display-cover behavior end to end.

CLI 0.133.0 ships the new policy substrate alongside the goal-default-on move: permission profile inheritance hierarchies (a profile can derive from another), managed requirements.toml integration as an org-level enforcement file, runtime profile refresh, and list APIs for profile discovery. CLI 0.134.0 then makes --profile the canonical permission selector across CLI, TUI, and sandbox flows, rejecting legacy profile configs with migration guidance. Enterprise operators can now prototype base profile + per-team derivations rather than maintain flat grant lists. The discipline constraint: prototype but do not rely on managed requirements.toml as enforceable policy until the file's distribution, signing, and inheritance merge semantics are documented or verified through adoption — the underlying policy mechanism is real, but the category claim ("this is the enterprise policy model for coding agents") is not yet receipt-backed and should not be made.

Posture basis: 2026-05-07-codex-stateful-control-plane, 2026-05-11-codex-permissions-visibility-and-plugin-share-evolution, 2026-05-12-codex-pretooluse-input-rewrite, 2026-05-27-codex-goal-mode-graduated-and-remote-computer-use, 2026-05-27-codex-permission-profile-inheritance-and-managed-requirements.

Open Questions

• What is the distribution and signing model for managed requirements.toml? Release notes describe org-level enforcement but do not document whether the file is repo-rooted, org-rooted via a central distribution mechanism, signed against tampering, or watched at runtime.
• Profile inheritance semantics: does a derived profile only add to the base, or can it subtract? Subtraction is the harder and safer feature; the release notes do not say.
• Runtime profile-refresh consistency under in-flight tool calls is unspecified — what happens to a tool call that started under a loosened profile that tightens mid-call?
• For remote computer use after Mac lock: can operators narrow the permission per-task / per-tool / per-domain beyond the documented short-lived authorization + relock-on-input + covered-display safeguards?
• Carried from the source contract: which GitHub releases, tags, and npm package versions should be treated as canonical when they disagree with the official Codex changelog? Which provider-native long-horizon features should Bitter detect through local probes rather than relying on release notes? See sources/codex.yml#discovery.
• surface_class migration trigger: Codex is currently classified mixed_official_docs. PR-level receipts for semantics-heavy features (permission profile inheritance, managed requirements.toml, goal lifecycle metrics) remain visible on openai/codex, so the classification holds. The pressure-test surfaced an open question for when migration to closed_source_release_notes would be triggered. Proposed trigger: when two consecutive cycles produce no semantics-heavy claim that can be anchored above release_note precision, the classification should move. Until then, evidence_floor: release_note stays, but profile claims reaching above release-note precision should cite the PR or docs page explicitly.

What To Watch Next

• Whether goal-mode-default-on is reversed or refined under operator pushback. The default-on move puts Codex in a small group with Claude Code and Gemini CLI; whether one of them reverses creates a marker for the industry.
• Adoption of requirements.toml outside OpenAI's own enterprise customers — distribution and trust model decisions will mostly emerge through adopters, not changelog entries.
• Whether plugin marketplace sharing (ChatGPT Business launched 2026-05-21; Enterprise "coming soon") materializes meaningful distribution mass; the surface exists but the adoption is the signal.
• codex exec resume --output-schema (CLI 0.132.0): a contract-bearing resume surface that lets a CI caller enforce schema on continuation of an existing session. Watch for adoption patterns and whether the schema-on-resume becomes standard for non-interactive callers.
• Conversation history search (CLI 0.134.0): a small surface, but the first time sessions are treated as searchable artifacts rather than ephemeral logs.
• readOnlyHint concurrency for MCP tools (CLI 0.134.0): possible cross-vendor convention candidate. Cross-provider probe worth scheduling.
• App-server consolidation (skills watcher, app-server pagination) is ongoing. Likely to absorb more surfaces.
• Remote control surfaces mentioned in the 0.130.0 changelog are worth a diff-level probe.