Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 19 Sep 2026

Harness integration

UHP and Codex

HarnessRouter Community Edition lists Codex as a supported harness backend and the UHP specification uses codex as an example stable base string. Upstream Codex now has richer task delegation, persisted goals with automatic continuation, authorization-state tracking, and stronger MCP/tool lifecycle controls, but those product capabilities do not make Codex tasks UHP tasks or establish native UHP adoption by OpenAI.

Verified: Protocol: 2026-09-12Static SSG

Verified relationship

Section titled “Verified relationship”

HarnessRouter Community Edition lists Codex as a supported harness backend and the UHP specification uses codex as an example stable base string.

In the UHP model, the product does not need to speak a Codex-specific product integration. It targets a configured harness through the UHP server. The server is responsible for driving the actual backend and translating its execution into UHP tasks, sessions, events, artifacts and errors.

What UHP tries to normalize

Section titled “What UHP tries to normalize”
  • Task submission and terminal status.
  • Progress streaming.
  • Session continuation.
  • Files and artifacts where supported by the conformance class.
  • Cancellation behavior.
  • Structured errors and capability discovery.

HarnessRouter skill-loader integration (released in v0.9.0)

Section titled “HarnessRouter skill-loader integration (released in v0.9.0)”

HarnessRouter’s runner now installs configured Codex skills where Codex’s own loader expects them: .harness/home/.codex/skills, corresponding to $CODEX_HOME/skills/<name>/SKILL.md after HarnessRouter redirects CODEX_HOME into the checkpointed workspace.

Before this fix, HarnessRouter wrote Codex skills to .harness/skills and relied on an AGENTS.md block to point the model at them. The upstream HarnessRouter defect report records a concrete failure mode: a model read the skill document but resolved a referenced test.py from the workspace root instead of the skill directory. The released fix makes the native skill loader responsible for presenting the skill and its directory semantics.

This is HarnessRouter integration behavior, not evidence that OpenAI/Codex natively implements UHP.

Current upstream release boundary

Section titled “Current upstream release boundary”

The latest observed stable upstream Codex release is 0.155.1, published 18 September 2026 at 20:03:04 UTC, with tag target be2951ea34f0d295ed0becf97079f92fa5f6950e. A newer 0.156.0-alpha.4 prerelease exists at this cutoff, but it does not supersede the stable line.

0.155.1 is a focused compatibility hotfix for the 0.155.0 TUI default. New local sessions in 0.155.0 requested detailed reasoning summaries by default, which could make otherwise valid Responses requests fail against providers that do not support reasoning summaries. The patch restores none as the default while preserving explicit auto, concise and detailed settings, including concurrent summary delivery when explicitly enabled. Upstream reports nine focused regression tests, all 4,589 non-ignored TUI tests across the rerun/follow-up, and release-build checks on Linux, macOS and Windows; the PR also records unrelated pre-existing CI failures outside the changed TUI files.

The release branch otherwise inherits the 0.155.0 harness/runtime baseline, whose material changes include:

  • MCP user verification: supported local TUI sessions can require native user verification for MCP requests, including Touch ID on supported Macs.
  • Daemon continuity: Codex adds configurable app-server daemon update schedules, an explicit daemon update command, and recovery of saved threads and active goals after daemon restarts.
  • MCP OAuth state: expired OAuth credentials and reconnect guidance are reported more accurately when refresh fails.
  • Authorization and isolation: automatic approval reviews preserve authorization evidence more reliably, account switches invalidate remote-control/model state belonging to the previous identity, and Windows/WSL sandboxing receives additional hardening.

These are upstream Codex harness/runtime capabilities. They do not change UHP or MCP wire semantics, establish native UHP adoption by OpenAI, or prove that HarnessRouter’s Codex adapter exposes the new verification, daemon or account/sandbox control surfaces through UHP.

The preceding 0.154.0 release remains relevant as the prior stable boundary: it introduced experimental managed worktrees, inline question handling while work continues, a Windows daemon runtime and additional MCP OAuth coordination. HarnessRouter Community Edition v0.18.4 still deliberately pins Codex 0.154.0 in its current docker/entrypoint.sh; the upstream comment says that pin is the support-matrix version and that a bump requires a PR with a matrix rerun. Upstream Codex 0.155.1 therefore must not be represented as the Codex version currently packaged/tested by HarnessRouter.

The prior 0.153.x patch line remains relevant history below. Its material runtime/app-server baseline is 0.153.0; 0.153.1 adds API configuration for GPT-6-Astra without changing the default model or exposing it in the model picker, 0.153.2 corrects Fast-tier display text without changing request execution, 0.153.3 adds GPT-6-Astra to Amazon Bedrock Mantle and Runtime global/US catalogs plus fixes its bundled asynchronous-clarification guidance, and 0.153.4 exposes Astra in the bundled model picker and makes it the bundled default when no model is explicitly configured while qualifying the async-question guidance so it only calls request_user_input_async when that tool is available.

Current-main evidence after the 0.154.0 cutoff

Section titled “Current-main evidence after the 0.154.0 cutoff”

OpenAI Codex PR #44826, merged on 11 September 2026 at 7a6f469dcff1337786aae046df2d899accea59ab, adds serverCapabilities to app-server mcpServerStatus/list results in both full and toolsAndAuthOnly detail modes, including thread-scoped reads. The field exposes the capabilities object advertised by the MCP server during initialization, including its extensions map, and is null when initialization did not establish capabilities.

Codex records that negotiated capability state independently from the shared tool catalogue. It retains advertised capabilities when later tool discovery fails, clears them on a new connection attempt and does not infer them from listed tools or a shared tool cache. Upstream tests exercise an advertised openai/settings extension whose metadata points to settings.read and settings.update, plus degraded discovery and initialization-failure cases.

PR #44832, merged later on 11 September 2026 at 654b0a77d0d2f81aa21f61caf7af4be88fe550bb, adds a separate trusted configuration boundary for future enterprise-managed MCP authorization. Codex introduces auth = "ema_auth", a shared mcp_enterprise_managed_auth IdP configuration and per-plugin enterprise registration metadata, while constraining where those settings may originate.

The important change is authorization provenance and anti-downgrade enforcement. Enterprise registrations must resolve from one non-project configuration layer, managed IdP precedence is preserved, and project configuration cannot redirect the enterprise credential source, change the selected enterprise authorization, or re-enable an enterprise server disabled by a higher-trust layer. Plugin MCP declarations are explicitly rejected if they attempt to self-select ema_auth. Ordinary MCP OAuth login and credential fallback are also blocked for this mode. The related use_xaa feature is disabled by default and cannot be enabled solely from project configuration; it requires non-project opt-in or a managed requirement.

PR #44938, merged on 11 September 2026 at 2e572378f42c35138e33b7bdb716c3082511defe, separates connector authentication-failure classification from the availability of an installation URL. The new codex-mcp classifier recognizes an authentication failure only when the MCP tool result is an error, carries the explicit Codex Apps auth-failure flag and can be bound to a nonempty trusted connector ID; if the result metadata names a connector, that identity must match. Upstream tests cover missing_link, oauth_upgrade_required and reauthentication_required, while rejecting missing/mismatched connector identity, ordinary errors and successful results. The existing richer parser still requires an install URL before it can construct the install-oriented auth-failure object, so classification and remediation are now distinct stages rather than one implicit condition.

PR #44939, merged eight minutes later at c210f4c222f8f7a447d0b3a013f3cb9cc3cd43b0, makes the Windows sandbox setup owner follow the execution host. Local sandbox setup prompts/actions run only when both the app-server connection and selected executor are local, including local-daemon connections. Remote servers own Agent permission selection; mixed local/remote executor configurations suppress local sandbox setup and surface a warning instead of letting the TUI configure a sandbox it does not own. When elevated local sandboxing is required, startup asks the local app server for WindowsSandboxReadiness, preserves successful setup state across widget replacement/reconnects, and restores pending initial input when mixed executors or a local connection failure prevent setup.

PR #44944, merged on 12 September 2026 at 39d193d72d7959d798642bd3e1496bb8865033b1, makes managed model-provider requirements live constraints on retained app-server threads. Before turn start/steer, review, compaction, manual queue start and active goal updates, Codex compares the thread’s retained provider selection and definition with the current managed model_provider / model_providers requirements. If those requirements cannot be loaded or no longer match, the operation is rejected instead of continuing under stale organization policy; provider mismatches direct the user to restart Codex. The check intentionally reads managed requirements independently of user, project and system defaults or retained thread configuration, and resolves Amazon Bedrock provider overrides before comparison. Interrupt, realtime stop and goal pause/clear remain available, while realtime connections use separate routing.

PR #44945, merged eight minutes later at cebdb732eacfeae9823be93aad273c242428b8a0, completes the Windows sandbox ownership shift by routing elevated and unelevated setup through app-server windowsSandbox/setupStart. The TUI no longer runs sandbox setup helpers directly or writes sandbox-mode configuration itself. It keeps setup pending when the start request times out or its response is lost, blocks thread replacement while setup is unresolved, ignores completion notifications for a different mode and verifies the effective sandbox mode before enabling Agent mode. Reconnect interruption clears stale setup state with restart guidance; elevated failure preserves the fallback prompt and unelevated failure is reported explicitly.

PR #45185, merged on 13 September 2026 at 1715e55076737158ba61d43158ede504de6d4ce1, hardens direct tool-call provenance and completeness across history capture. Codex now binds each direct-call record to the invocation output that produced it before that output enters history, so reuse of a call ID cannot associate a later result with the wrong earlier invocation. tool_calls_complete now describes whether the recorded invocation arguments are complete, independently of whether the tool itself succeeded.

The capture lifecycle is bounded as well: pending and retained metadata reservations are released on completion or cancellation; disabling capture invalidates pending records and strips direct-call metadata from inference and compaction inputs; executed-call metadata is removed from raw app-server response notifications and excluded from Guardian history-retention budgets; and call IDs that bypass dispatch cannot later be reused to manufacture Code Mode completeness. Upstream regression coverage spans attribution, malformed calls, metadata budgets, cancellation, configuration changes, compaction, notification filtering and Guardian context isolation.

PR #45248, merged on 13 September 2026 at 16537b20a5ec0ea9aa079f4ad4b0e30e8a9efacf, fixes step-scoped execution-metadata attribution across Responses, MCP, extensions and hooks. Codex can change model and reasoning effort during a turn; request metadata and tool hooks could therefore report the turn’s initial settings instead of the settings captured for the step that actually issued the request or tool call. The merged path now shares captured model, reasoning effort, automatic-review and Node REPL flags across Responses, MCP and extension tool calls, builds Responses tool-inventory metadata from the issuing step’s finalized tool router, carries that finalized inventory separately for remote compaction, and uses captured step/review settings for pre-tool, post-tool and permission-request hooks.

This matters because telemetry, policy hooks, MCP metadata and remote-compaction provenance can otherwise describe a different execution configuration from the one that actually produced an action. Upstream adds and extends regression coverage for mid-turn model/effort changes, MCP metadata, pre-tool model attribution, captured review flags and tool-inventory matching. This is Codex host/runtime metadata integrity, not an MCP or UHP wire change.

Together, #44826, #44832, #44938, #44939, #44944, #44945, #45185 and #45248 expose eight distinct host-side boundaries: what an MCP server advertised, which configuration layers may select enterprise authorization, whether connector auth failure can be trusted independently from a remediation URL, which execution host owns sandbox setup, whether a retained provider route still satisfies current managed requirements, whether Windows sandbox setup reaches a verified app-server-owned completion state, whether recorded direct tool history remains attributable and completeness-safe across reused IDs and capture-lifecycle changes, and whether request/tool metadata and hooks remain bound to the exact captured execution step that issued them.

Those eight commits were previously tracked from the upstream main lineage after stable 0.154.0. They are not automatically reclassified as 0.155.0 or 0.155.1 release contents merely because the stable release advanced: the 0.155.1 release branch diverges from the reviewed current-main lineage. They remain source-pinned current-main evidence unless a release/tag source independently establishes the same shipped change.

A later current-main control, PR #46335 at 7498521d288b9b3b96ffba4eedf089d8d6e06a84, makes MCP policy evaluation consistent with the active turn’s environment snapshot. If environment settings are changed while a turn is waiting for user input, that next-turn policy must not mutate MCP tool availability when the same active turn resumes. Codex now evaluates/publishes MCP runtime state from one captured turn environment and applies the saved policy change on the next turn. Upstream regression coverage verifies the tool remains visible when the waiting turn resumes and disappears on the subsequent turn.

Two post-0.155.1 merges add a complementary workspace/execution-host ownership boundary. PR #46494, merged on 18 September 2026 at 6d29cc6bac4c3099d604cdc0d0dd96215d197974, stops client-host runtimeWorkspaceRoots from overriding a remote app server’s workspace roots during start, resume and fork. Remote launches reject client-local --add-dir and sandbox_workspace_write.writable_roots overrides before connecting, while server-provided roots survive active-session and side-conversation forks even after client configuration reloads. The rule is narrow: workspace roots follow the execution host; unrelated network-access overrides remain allowed.

PR #46498, merged later on 18 September 2026 at e49739355235bb1ac27df799327227be23e87e94, shows the inverse composition boundary for managed worktrees: workspace allocation can stay client-owned while execution reuses an existing local daemon. --worktree and boolean features.worktrees overrides remain daemon-eligible, other configuration overrides and --no-daemon remain exclusions, and a --worktree launch does not auto-start the daemon. Upstream tests run the worktree startup/fork scenarios against both embedded and daemon backends and verify ownership before the first turn.

PR #46547, merged on 19 September 2026 at c026e7a622ecae45f0af1939729e7baab9d1637b, makes that composition boundary more explicit by introducing a public, object-safe AgentControl contract for coordinating one Codex agent tree independently of where its threads run. The trait covers lifecycle operations (spawn, resume, interrupt, close), message delivery, inspection/listing/watch, tree-wide execution admission, usage accounting, terminal turn outcomes, shared configuration propagation, Guardian evidence and budget reminders. The implementation contract distinguishes a local or host backend from transport details: hosts own transport, durable acceptance, retry identities and recovery, while the Rust API itself explicitly does not define a wire protocol.

The ownership semantics are material. ControlIdentity combines the session identity with an owner generation so a replacement owner can fence a stale controller; mutation success means the backend accepted an operation rather than proving the requested agent work completed. AgentExecutionGuard now owns a backend-provided reservation, with tests covering reservation release when the guard is dropped or a turn is cancelled. GuardianRootSnapshot also carries the root thread identity so authorization evidence remains attributable to the tree that produced it.

The reusable boundary is: agent-tree coordination can be backend-independent without becoming transport- or protocol-independent. A composed harness still needs explicit ownership generations, admission/reservation lifetime, delivery acceptance versus completion, usage/outcome idempotency and authorization-evidence provenance across whatever backend boundary it chooses. This is Codex internal control-plane architecture, not a new UHP, MCP, A2A or ACP primitive and not evidence that OpenAI has adopted UHP natively.

Checked upstream main is c026e7a622ecae45f0af1939729e7baab9d1637b at this cutoff, the merge commit for PR #46547. PR #46335, #46494, #46498 and #46547 are current-main behavior outside the 0.155.1 release tag, and none establish native OpenAI UHP adoption or prove that HarnessRouter exposes these controls through UHP.

Codex 0.151.0: MCP lifecycle, persisted goals and budget integrity

Section titled “Codex 0.151.0: MCP lifecycle, persisted goals and budget integrity”

OpenAI released stable Codex 0.151.0 on 29 August 2026. The release materially changes the harness’s MCP/tool lifecycle and several control boundaries that matter when Codex is embedded inside a larger agent system.

Optional MCP-server discovery now has a configurable shared startup grace through mcp_optional_startup_grace_ms, defaulting to 1,000 ms. Setting it to 0 disables the shared grace so optional servers fall back to their configured startup_timeout_sec; runtime and MCP configuration refreshes also update the grace and reset cached startup deadlines when its duration changes. This makes optional-server tool-catalog discovery policy explicit rather than fixed.

Codex extensions can also participate after an MCP tool executes but before the result reaches the model. The new ToolLifecycleContributor::on_mcp_tool_result hook receives the executed tool context, rewritten arguments, extension data stores and a mutable server result. Contributors can inspect or replace successful and error results; Codex waits for that processing before publishing completion, and the processed result is used both for completion events and subsequent model input.

That is an important trust boundary for host integrations, but it should not be conflated with the separate MCP Interceptors standards work. 0.151.0 is documenting a Codex extension lifecycle hook around MCP results, not a new UHP primitive or proof that Codex implements an MCP Interceptors specification.

The release also tightens execution integrity around that surface: restored permission profiles persist across TUI turns, /cd can no longer weaken sandbox restrictions, stale Guardian classifications cannot authorize actions after permission state changes, and app-server responses preserve structured MCP tool/resource errors. Plugin catalogue requests now combine effective per-repository configuration while reporting invalid project marketplaces without hiding valid catalogues.

The 0.151.0 tag also ships Codex’s Goals feature as Stable and default-enabled. App-server exposes a single persisted goal for a materialized thread through thread/goal/set, thread/goal/get and thread/goal/clear, with thread/goal/updated and thread/goal/cleared notifications. A goal can carry an objective, token budget and lifecycle status such as blocked, budgetLimited or usageLimited; goals.max_goal_token_budget can impose a configured ceiling/default. Codex can automatically continue an active goal across turns, while the experimental thread/fork option deferGoalContinuation can carry the source goal into a fork, run one explicit turn first and then resume automatic continuation.

For nested-agent execution, Codex now rolls token usage from spawned descendants — including nested subagents — into the root goal’s usage and token budget during active and idle accounting. The implementation explicitly tests child and grandchild usage, budget exhaustion, goal replacement and concurrent checkpoints. This closes a resource-accounting gap where delegated descendants could otherwise sit outside the root goal’s budget view.

Codex 0.152.0 / 0.152.1: lineage, Guardian review integrity and MCP policy

Section titled “Codex 0.152.0 / 0.152.1: lineage, Guardian review integrity and MCP policy”

OpenAI published stable Codex 0.152.0 on 1 September 2026 and patch 0.152.1 later the same day. Tag comparison shows 0.152.1 is only three commits ahead of 0.152.0: one substantive Guardian-policy backport plus the patch-branch preparation and release-version stamp. The 0.152.0 tag contains the #41562/#41567/#41660/#41700/#41846–#41861 lines this guide previously tracked as post-0.151.0 current-main behavior; 0.152.1 adds the narrower Guardian REPL policy correction described below. Later executor-permission and plugin/runtime work remains outside that patch tag and is released in 0.153.0, kept separate below.

0.152.0 also adds a positive per-tool output_token_limit under each MCP server’s tools configuration. When plugin and user policies overlap, Codex keeps the most restrictive explicit output budget while leaving approval policy independent. The effective budget is carried in conversation history so MCP tool output, post-tool hook responses and resumed sessions use the same truncation limit instead of silently reverting to a different budget after persistence or replay.

This is a Codex MCP client/configuration policy, not a change to MCP wire semantics and not a UHP output-budget primitive.

Patch 0.152.1 cherry-picks PR #41919 onto the stable branch so Guardian’s node_repl / cua_repl review policy can come from the selected reviewer model’s auto_review.node_repl_policy metadata. If that field is absent Codex falls back to its bundled policy; if it is explicitly empty the extra policy injection is skipped. Codex also makes the effective policy part of Guardian review-session reuse identity, so a policy change invalidates the cached reviewer session, and it rejects parent-model fallback transitions that would silently change the policy.

This is a review-policy provenance and cache-integrity boundary inside Codex. A reused Guardian session must still correspond to the policy selected for the reviewer model rather than inheriting stale policy text from an earlier model/session. It is not an MCP policy field, UHP review primitive or portable agent-policy format.

After the 0.151.0 tag was cut, Codex PR #41562 merged on 29 August 2026 to preserve trustworthy turn lineage across automatic goal continuations. Successive automatic continuation turns now retain the trusted root and prior parent-turn relationship that originated the goal. Codex invalidates stored lineage when external input reaches the active turn, when hook context is not attributable to the receiving turn, or when the goal is edited or cleared, so stale lineage is not carried into later autonomous work.

This is a material control-plane integrity fix for persistent autonomous execution: a host can distinguish continuation work that still belongs to the original goal lineage from work whose attribution became ambiguous after outside intervention.

A second post-0.151.0 change, PR #41567, merged at f5636bb7 on 29 August 2026 and hardens persisted working-directory state across resume, forks and compaction. When thread/resume omits cwd, Codex now restores only the latest retained settings snapshot explicitly owned by that thread; copied settings from another thread cannot silently become the resumed thread’s working directory. Legacy settings snapshots without an owner remain readable but do not override the startup cwd, while an explicit resume cwd remains authoritative.

Successful compaction now checkpoints the current thread settings into retained history, and settings checkpoints are serialized with settings updates, so the bounded replay window still contains an accepted current working-directory snapshot. Upstream coverage spans compaction, forks, reverts, legacy histories and concurrent settings updates.

A third post-0.151.0 change, PR #41660, merged on 30 August 2026 at 0a12b855, separates Guardian authorization freshness from the generation of the model-visible conversation history. Codex now tracks a host-owned user_message_revision for authorization decisions instead of treating every history rewrite as an authorization change. Genuine user messages and history resets advance that revision; history compaction and host-injected internal context do not. As a result, a previously valid Guardian review can remain reusable across compaction without being mistaken for a new user authorization event.

The implementation uses message content-kind metadata to distinguish host context from user input. Unknown, incomplete or legacy metadata is handled conservatively as user authorization rather than being silently trusted as internal context. Upstream regression coverage verifies that cached Guardian authorization survives compaction and internal context injection but is invalidated by genuine user input and rollback/reset behavior.

This is a narrow but important trust-boundary correction: compaction can rewrite what the model sees without changing what the user authorized, while genuine user changes must still invalidate stale authorization evidence. The change reduces unnecessary re-review caused by internal history maintenance without allowing compaction itself to refresh or extend authority.

A fourth post-0.151.0 change, PR #41700, merged on 30 August 2026 at 94cbbdda, fixes an MCP naming restriction that rejected package-style server identifiers. Codex now accepts :, @, / and . in MCP server names, allowing identifiers such as npm:@modelcontextprotocol/server-sequential.thinking rather than requiring callers to flatten them into alphanumeric/underscore/hyphen aliases.

The change preserves the original server name through codex mcp add|get|list|remove, runtime MCP metadata and OAuth credential lookup while still converting the name into a model-safe callable namespace. Generated config.toml recovery hints quote non-bare names correctly, and OAuth storage adds collision-isolation coverage for escaped/repeated local: identities. Upstream tests cover CLI round trips, stdio runtime namespace normalization, recovery-hint snapshots and OAuth credential-name collisions.

This is a practical MCP interoperability correction at the Codex client/configuration layer: package-shaped identities can survive configuration and runtime plumbing without being silently renamed. It does not change MCP’s wire protocol, define an MCP package-naming standard, or establish a UHP mapping.

A fifth post-0.151.0 change, PR #41846, merged on 31 August 2026 at 1c1e1778, closes a different compaction boundary from #41660. PR #41660 separated Guardian authorization freshness from model-history generation, but Guardian could still build approval-review transcripts from the compacted conversation snapshot; compaction could therefore replace original user or tool evidence that a later approval-sensitive review still needed.

Codex now keeps a bounded chronological review history independently of the model’s compacted history. User messages and other transcript items have separate retention budgets so heavy tool traffic cannot evict user instructions from the evidence available to Guardian. In released 0.152.0, synchronous and asynchronous Guardian reviews consume that retained evidence, while rollback and explicit history reconstruction reset it instead of carrying stale pre-reset evidence forward.

Upstream integration coverage exercises the boundary directly: a thread records the instruction “Only publish to a private repository,” produces 130 tool calls so ordinary retained history evicts early tool traffic, compacts, and then verifies that a later approval-sensitive publish review still receives the retained user restriction and relevant review evidence in chronological order. The same test verifies that rollback removes the pre-rollback retained evidence.

Four same-day follow-ups close additional evidence and reviewer-isolation edges in that Guardian path. PR #41852 (305eed10) makes trusted request_user_input answers survive compaction and review-history eviction by correlating them with the retained original tool call, while explicit rollback still removes the associated answer. PR #41857 (98a8425e) broadens that correlation to accept the original tool call from either the current conversation or retained review history, so a still-current interaction is not accidentally excluded just because it has not moved into the retained buffer.

PR #41858 (09f4c450) handles oversized multimodal user messages. Previously, if an attached image pushed a user message beyond Guardian’s 4 MiB per-kind review-history budget, the entire message could be skipped, including adjacent user instructions. Codex now omits the oversized image but retains the message’s text and metadata in order; other oversized history items keep the previous skip behavior. Upstream coverage includes a valid image whose encoded payload exceeds 4 MiB and verifies that the user restriction remains available to a later Guardian review.

PR #41861 (2c8cfbf4) narrows the Guardian reviewer subthread itself. Reviewer subthreads now initialize with empty extension data, and Codex removes the special registration that exposed inherited read-only history extension tools — including list_windows, list_items, read_item and search_contents — in the Guardian tool plan. This removes that extension route back into parent-thread history while leaving the host-assembled Guardian review-evidence path as the documented review input.

Together, #41660 and the #41846/#41852/#41857/#41858/#41861 sequence separate and harden complementary controls that compaction previously blurred: #41660 decides whether cached authorization is still fresh; the #41846 family preserves the evidence Guardian evaluates; #41861 narrows the reviewer capability surface so inherited history-extension tools are not additionally exposed. Compaction may change model-visible history without silently erasing approval evidence, while rollback or history reconstruction intentionally rebases both authorization/review state and the evidence used to judge later sensitive actions.

These lineage, owned-resume-state, authorization-freshness, MCP-name and Guardian-evidence/reviewer-isolation changes are released in the 0.152.0 baseline; stable 0.152.1 carries that baseline plus the model-provided Guardian REPL-policy correction.

Codex 0.153.0 stable: executor permissions, plugin/runtime controls, Guardian authority, account-scoped MCP approvals and thread lineage

Section titled “Codex 0.153.0 stable: executor permissions, plugin/runtime controls, Guardian authority, account-scoped MCP approvals and thread lineage”

OpenAI released 0.153.0 on 3 September 2026, shipping the coordinated runtime and app-server work this guide had previously tracked only on upstream main. The release notes also expose remote-marketplace plugin CLI operations, richer app-server thread metadata (model and reasoningEffort), structured asynchronous user-input requests, disabled-by-default experimental context management, and TUI/app-server reconnection hardening. These are Codex product and app-server surfaces, not UHP wire semantics.

PR #41909 (b51b0778) followed by PR #41928 (c4350b4c) on 31 August 2026 moves additional-filesystem-permission handling onto the selected executor’s path semantics rather than the local host’s path convention. Codex now resolves project roots, temporary directories, home-relative deny globs and filesystem roots through the executor’s FileSystemSandboxPolicyContext, preserves POSIX, Windows and UNC URI conventions, and keeps deny constraints while intersecting grants.

PR #41928 applies the same executor-aware context to permission preapproval for exec_command, apply_patch and extension tools. That matters when a grant belongs to a remote executor whose path convention differs from the host: for example, a Windows executor selected from a non-Windows host. Symbolic tmpdir or project-root grants now fail closed when the executor metadata required to resolve them is unavailable, while opaque working-directory URIs remain usable when the requested paths use the executor’s own convention. Upstream tests cover Windows grants reused from a non-Windows host, symbolic temporary-directory resolution, opaque Windows working directories, POSIX/Windows/UNC deny-glob behavior and incompatible path conventions.

This closes a practical authorization-boundary mismatch in composed/remote execution. A permission grant is interpreted in the filesystem namespace of the executor that will perform the action, rather than being accepted or rejected through the host machine’s unrelated path syntax.

A second composition line, PR #41949 (bfa96467), merged on 1 September 2026, adds the app-server plugin/reconcile method for installed remote plugin bundles. A reconciliation pass synchronizes those bundles against current plugin-service state and blocks until synchronization plus required hook updates finish. Its response identifies plugins changed by bundle updates, enablement changes, cached reinstalls or removals and carries hasMcps, hasApps, hasHooks and hasSkills refresh hints, plus separate remote-update and materialization-failure lists.

Those flags describe runtime categories affected by the observed bundle change, not a runtime-readiness acknowledgement or post-policy inventory. Removals retain the old bundle’s affected categories, the skill flag means that a bundle declares skill roots rather than proving an enabled skill inventory, and a materialization failure can leave a previously cached bundle available. Codex refreshes loaded hook runtimes inside reconciliation; app-server clients are expected to refresh MCP and Apps runtimes, while plugin skills are discovered on subsequent turns.

This creates an explicit host↔harness synchronization boundary for multi-surface plugin bundles instead of forcing a client to infer when MCP servers, Apps, hooks or skills changed. It is Codex app-server/plugin lifecycle behavior, not an MCP extension, UHP discovery mechanism, portable plugin standard or UHP mapping.

A third line, PR #41953 (633ab199), merged on 1 September 2026, extends Codex’s existing marketplace-source restrictions to the two local curated plugin catalogues backed by the OpenAI plugins Git repository. The same Git-source allowlist now gates curated catalogue discovery, installation, cached plugin and skill loading, and startup repository synchronization. Blocking that curated Git source does not block bundled plugins or remote-installed plugins, which remain separate policy categories.

This closes a plugin supply-chain/source-policy gap inside Codex: a restricted installation no longer treats built-in curated Git catalogues as an implicit exception to its configured source policy. It is a Codex plugin-policy boundary, not a UHP trust primitive, MCP rule or portable marketplace standard.

A fourth line, PR #42065 (28097e98), merged on 1 September 2026, changes how retained Guardian review evidence survives thread reconstruction. Codex now writes the bounded, model-invisible Guardian transcript into compacted rollout checkpoints and restores it from the newest surviving checkpoint during replay. A compacted thread can therefore retain review evidence across restart/resume and a user-initiated fork instead of reconstructing with an empty Guardian history.

The boundary is intentionally asymmetric. Rollback trims Guardian history at the rollback boundary and clears it when the relevant boundary has already been evicted; a spawned subagent explicitly drops the parent’s Guardian checkpoint so parent-local review evidence cannot grant authorization in the child context. The new compacted-rollout field is optional for compatibility with existing records and legacy readers. Upstream tests cover compaction, restart, paginated and pathless stores, user forks, rollback, bounded replay, serialization and subagent forks.

This closes the persistence gap left by the released 0.152.0 reconstruction behavior: review evidence can survive legitimate reconstruction without crossing a rollback or parent→subagent authority boundary. It is Codex-internal authorization/replay state, not a UHP session primitive, portable approval artifact or UHP↔Codex mapping.

A fifth line, PR #42121 (91125641), merged on 1 September 2026, makes the approval reviewer mutable during an already active turn through experimental turn/settings/update. A client can switch approvalsReviewer between user and auto_review for subsequently captured steps and newly initiated background approval requests. Already captured steps and pending approvals keep their original reviewer, future-thread defaults remain separate, and managed reviewer restrictions plus model-required automatic review continue to reject incompatible updates. The update does not approve a pending request, change sandbox permissions or update child sessions. Codex’s MCP approval path can issue an explicit live reviewer update while clients that do not set one continue to follow refreshed thread defaults.

This creates a narrow live authority-versioning boundary: changing approval policy mid-turn affects newly captured approval-sensitive work without retroactively rewriting authority already attached to captured steps or pending requests, and without silently leaking the turn-local reviewer into future threads. It is an experimental Codex app-server/runtime control, not an MCP approval feature, UHP primitive or portable reviewer protocol.

A sixth line, PR #42135 (c5b5fa80), merged on 1 September 2026, hardens persisted thread-lineage references when Codex’s managed sessions directory is itself a symlink. Forking a resumed paginated thread had rejected a valid rollout under that symlinked managed root. Codex now canonicalizes the candidate rollout and the managed sessions / archived_sessions roots before deciding whether a reference is in scope.

The rule is deliberately narrower than accepting any canonical path under Codex home: a rollout underneath the canonical target of a managed root is accepted, while a nested symlink that escapes that canonical managed root is rejected. Upstream regression coverage tests both the legitimate symlinked-root fork and an escape through a nested directory symlink.

This is a persistence/confinement correction for Codex thread lineage: deployment layouts may relocate managed session storage through a root symlink without breaking forks, but a reference-backed lineage path cannot escape the canonical managed session stores through a nested symlink. It is Codex thread-store behavior, not UHP session semantics, a portable artifact-path rule or evidence that HarnessRouter exposes Codex’s internal rollout paths through UHP.

A seventh line is a five-PR connected-account approval sequence merged on 1 September 2026. PR #42047 (0ec375eb) adds per-account App configuration at apps.<app_id>.links.<link_id> for approvals_reviewer and default_tools_approval_mode. PR #42054 (0e37d834) resolves a required link_id from Apps tool-call arguments and rejects a missing, empty or non-string selector before approval or execution, while leaving non-Apps MCP tools unchanged. PR #42056 (3a044826) then feeds the resolved link into MCP approval-policy evaluation so link-specific reviewer and default tool-approval settings are consulted before app/global defaults, while per-tool settings and managed policy retain precedence.

The later PR #42133 (2393b5c9) closes the remembered-approval boundary: Codex’s session MCP approval key now includes link_id, so approval remembered for a connector/tool on one selected account cannot be reused for another account or for a call without that link selector. PR #42134 (a30fa3d) carries the same selected link_id into native MCP approval elicitation metadata and marks IDs using the reserved implicit_link:: prefix with link_is_implicit, allowing the approval surface to retain the account-link context that will govern execution.

Architecturally, the sequence makes selected account-link identity part of authorization scope, not merely connector/tool identity. That reduces a confused-deputy class where a broad or remembered approval for one connected account could otherwise authorize the same tool against another account. This is Codex Apps/MCP-client authorization behavior; it does not change the MCP specification, define a portable MCP account-link field, create a UHP authorization primitive, establish native OpenAI UHP adoption, or show that HarnessRouter exposes these Codex account-link controls through UHP.

An eighth line, PR #42147 (e5769939), merged on 1 September 2026, makes Codex’s Full Access state explicit at the Guardian/MCP review boundary. Codex recognizes Full Access only when approvalPolicy: "never" is paired with unrestricted permissions for the thread and every selected environment; pending, failed or restricted environments do not qualify. In that state, confirmation-only Guardian and MCP approval requests bypass synchronous Guardian review, sampler prewarming and background scoring. Explicit denials, cancellation and forms that require user input retain their existing behavior, and permission state is re-evaluated each turn so an existing thread can safely enter or leave Full Access.

This is a deliberate authorization-mode short-circuit, not a weaker Guardian verdict. Once the operator has selected unrestricted execution with no approval prompts, Codex does not spend a second model-review step on confirmation-only actions; unresolved or restricted execution contexts fail out of that classification instead of inheriting the bypass. This is Codex authorization/runtime behavior, not an MCP wire rule, UHP permission mode or portable approval protocol, and it does not establish that HarnessRouter exposes Codex Full Access through UHP.

Stable 0.153.0 therefore releases the executor-aware filesystem permissions, remote plugin-bundle reconciliation, curated-marketplace source-policy enforcement, Guardian review checkpointing across replay/resume/user forks with rollback/subagent isolation, turn-local live approval-reviewer updates with captured/pending/future-thread boundaries, canonical managed-root validation for reference-backed thread lineage under symlinked session storage, account-link-scoped Apps/MCP approval policy and remembered approvals, and Full-Access suppression of confirmation-only Guardian/MCP review that this page previously labeled current-main behavior.

Patch 0.153.1 adds support for configuring GPT-6-Astra through the API without changing the default model or exposing it in the model picker. Patch 0.153.2 only corrects the displayed Fast-tier description from “1.5x” to “2x speed, increased usage”; OpenAI explicitly states that request behavior does not change.

Patch 0.153.3, published 4 September 2026, adds GPT-6-Astra to the Amazon Bedrock catalogs for Mantle and Runtime global/US routes and updates Astra’s bundled asynchronous-clarification instructions to call the already-supported request_user_input_async tool, state that the tool is text-only and cannot gather file uploads or screenshots, and use 60 seconds as the example wait for optional clarification. OpenAI’s hotfix PR explicitly says this second change is prompt guidance only; Codex 0.153.0 already registered the tool.

Patch 0.153.4, published later on 4 September 2026, fixes a separate bundled-catalog visibility defect: Astra’s entry changes from visibility: "hide" to visibility: "list". OpenAI states that Astra’s existing priority therefore makes it the bundled default when no model is explicitly configured. The same patch qualifies Astra’s asynchronous-question instruction with “When available,” so bundled guidance no longer implies that functions.request_user_input_async exists in every session. The upstream PR records this second hotfix as a one-line prompt/catalog change rather than a new tool implementation.

These 0.153.3 and 0.153.4 changes are Codex model/provider, catalog and prompt-guidance behavior. They do not alter UHP or MCP wire semantics or establish native OpenAI UHP adoption. HarnessRouter v0.18.4 still pins Codex 0.154.0; that pin does not establish that these Codex model/provider/catalog/prompt surfaces are exposed through UHP.

Codex 0.150.0: task-to-task delegation and interrupt hooks

Section titled “Codex 0.150.0: task-to-task delegation and interrupt hooks”

OpenAI released stable Codex 0.150.0 on 26 August 2026 with a material expansion of Codex’s own task/composition surface.

The TUI can now expose a codex_tui tool namespace to an active Codex agent for listing, reading, waiting on, creating, forking, messaging, renaming, archiving and restoring other Codex tasks. Those operations use Codex app-server thread operations. Delegation-capable task tools are routed through an authenticated local MCP server with explicit approval prompts and continue to respect configured and managed MCP policy.

The same release adds task mentions to the TUI composer. Matching Codex tasks can appear in the @ picker, with tasks from the current working directory prioritized. A selected task is submitted as a bounded live thread reference so the agent can inspect it through read_thread; those references are preserved through history, start, resume and fork flows.

Codex 0.150.0 also adds an Interrupt hook for an active top-level turn. Before the interrupted-abort event is emitted, Codex flushes the turn transcript and can invoke configured command or MCP handlers with session, turn, transcript, working-directory, model and permission-mode context. Command handlers may be asynchronous; the implementation uses a one-second default timeout and a three-second maximum.

This release is useful evidence that Codex itself is becoming a more compositional harness: one Codex task can inspect, create, fork or message other Codex tasks, with MCP used as an approval-gated delegation transport inside the product. It does not establish native UHP support by OpenAI, and this maintenance pass did not identify HarnessRouter evidence specifically validating that the 0.150.0 task-delegation controls are exposed through its UHP adapter.

What is not proven

Section titled “What is not proven”

Why the distinction matters

Section titled “Why the distinction matters”

A reference implementation can adapt an existing harness without that harness vendor changing its own API. Native adoption would be a stronger ecosystem signal: it would mean a vendor, tool or independent runtime exposes or consumes UHP directly, reducing dependence on one adapter implementation.

Current developer implication

Section titled “Current developer implication”

If you are evaluating UHP today, test the behavior you need through the official conformance suite and your target backend. Do not assume that every backend feature maps perfectly just because the common API exists. The protocol deliberately defines common semantics, while backend-specific capabilities may continue to differ.

Section titled “Related pages”

Read harness composition and subagent delegation, UHP architecture, conformance, and the adoption tracker.

Primary sources

Section titled “Primary sources”