## Why
Finish the TestAppServer builder migration after every caller has moved
off the compatibility constructors.
## What
- remove the obsolete public TestAppServer constructors
- leave TestAppServer::builder() as the only fixture construction API
## Validation
- cargo check -p codex-app-server --tests
## Cleanup stack
1. [#31425 test: add TestAppServer
builder](https://github.com/openai/codex/pull/31425)
2. [#31451 test: migrate TestAppServer callers to
builder](https://github.com/openai/codex/pull/31451)
3. this PR
## Description
This PR moves review-mode markers onto canonical `TurnItem` lifecycle:
- `TurnItem::EnteredReviewMode`
- `TurnItem::ExitedReviewMode`
Core now emits `ItemStarted` / `ItemCompleted` for both. The completed
items map back into the existing `EnteredReviewMode` /
`ExitedReviewMode` events, so raw core event consumers and legacy
rollout persistence keep seeing the old events.
This is the compatibility layer needed before paginated rollouts persist
review markers as `ItemCompleted(TurnItem)`.
## Why
Review markers were one of the remaining app-server thread items created
directly from legacy events. Giving them canonical items lets paginated
history persist stable turn/item IDs without changing legacy rollouts.
## What changed
- Added canonical review-mode `TurnItem`s and switched review flow to
emit their lifecycle.
- Added completed-item → legacy review event mappings with stable
turn/item IDs.
- Switched app-server live notifications to the generic canonical item
path and kept legacy replay compatible with old payloads.
- Updated `ThreadHistoryBuilder` to replay canonical review items even
though review turns still do not emit `TurnStarted`.
## Description
This PR migrates standalone web search onto the extension-owned
turn-item path introduced in #31283.
Standalone web search now emits `ExtensionItem::WebSearch` through
generic `TurnItem::Extension`, while app-server still exposes the
existing typed `ThreadItem::WebSearch` JSON shape. Hosted Responses API
web search stays on core-owned `TurnItem::WebSearch`.
## What changed
- Added `web_search::WebSearchItem` and `WebSearchAction` to
`codex-extension-items` under the stable `web.search` kind.
- Collapsed `ExtensionTurnItem` to generic `{ item, legacy_events }` now
that no typed extension special cases remain.
- Kept the existing `WebSearchBegin` / `WebSearchEnd` compatibility
events and canonical-first ordering.
- Updated app-server projection/history and generated TypeScript; the
app-server JSON schema is unchanged.
## Why
The Codex JavaScript shim currently distinguishes npm and Bun installs,
but a global pnpm install falls back to npm. That causes the native CLI,
`codex doctor`, and update flows to report or run npm commands even
though pnpm owns the installation. pnpm also allows its global package
and bin directories to differ, so `PNPM_HOME` does not reliably identify
the package owner.
## What changed
- detect pnpm-managed installs by finding pnpm's
`node_modules/.modules.yaml` metadata from the launched JavaScript
entrypoint
- pass a mutually exclusive `CODEX_MANAGED_BY_PNPM` marker into the
native CLI
- represent pnpm in install context, doctor output, version checks, and
TUI update actions without changing the existing public
`InstallContext::from_exe` signature
- recommend `pnpm add -g @openai/codex` for pnpm-managed installs and
snapshot the rendered TUI update notice
Validated with the 9-test install-context suite, the focused pnpm TUI
snapshot test, and Node's syntax check for the launcher.
Closes https://github.com/openai/codex/issues/10294.
## Why
`subagent_usage_draws_from_the_shared_budget` intermittently fails even
when the shared-budget behavior is correct. `ResponseMock` records a
request before the custom Wiremock predicate is checked, so the
follow-up mock can also contain unrelated requests. In a [recent Windows
ARM64 run](https://github.com/openai/codex/actions/runs/28916285431),
`single_request()` saw all seven requests from the scenario.
## What changed
Select the request containing the follow-up user prompt before making
assertions. The test still requires exactly one matching follow-up
request and still checks that the root sees 50 tokens remaining after
the child uses its share.
This is test-only. Shared-budget behavior and the common response-mock
helper are unchanged.
## Summary
- classify plugin store and remote bundle I/O failures by privacy-safe
operation context
- include the normalized `sub_error_type` in structured plugin-install
failure warnings
- leave analytics events and schemas unchanged
## Why
Top-level error types such as `store_io` collapse multiple filesystem
operations, making logs harder to diagnose. The subtype identifies the
failed operation without logging paths or new exception details.
## Impact
Plugin-install warning logs gain an optional normalized subtype.
Analytics payloads, app-server APIs, and stored data are unchanged.
## Validation
- `just fmt`
- `just test -p codex-core-plugins -p codex-app-server` (1,235 passed;
14 failed and 6 timed out because local `sandbox-exec` was denied,
`test_stdio_server` was unavailable, or user-level skill fixtures were
loaded)
## Why
The remote compaction parity test compares legacy and v2 sessions
created with separate temporary homes. Those sessions can discover
different model-visible skill catalogs, so the request comparison can
fail even when the compaction and service-tier behavior matches.
This is the most frequent retry-saved full-CI failure in the recent
JUnit history.
## What changed
Normalize only the contents of `<skills_instructions>` before comparing
the captured requests. The opening and closing tags remain in the
comparison, so the test still catches a missing or misplaced skills
block.
The service-tier, compacted input, follow-up request, and
replacement-history assertions are unchanged. A focused normalizer test
covers the new behavior.
## Scope
This is test-only. It does not change runtime compaction or skill
behavior. Exact skill-catalog rendering remains covered by the dedicated
skills tests.
## Why
The encrypted MAv2 spawn test often reads the parent follow-up request
before the child has sent its first request. The response mock records
candidate requests before applying its specific matcher, so the test can
see an empty `agent_message` list even though delivery happens a moment
later.
## What changed
Wait for the recorded child request that contains `agent_message`, using
the same short bounded polling pattern already used in this test module.
The exact encrypted payload and communication-log assertions stay
unchanged.
This is test-only: it does not add product delays, loosen the assertion,
or change multi-agent behavior. No follow-up is expected.
## Summary
Selection rows reserve their first two columns for the selection cursor
and render into the menu surface's left gutter. The empty-state message
reused that shifted row area even though it has no cursor prefix, so `no
matches` appeared two columns to the left of the search field.
This renders empty lists at the inset list origin while preserving the
cursor gutter for non-empty rows.
Why
Filtering hidden directories after a walk is too late: their descendants
consume traversal limits, and canonical directory deduplication can let
a hidden path claim a target before a visible symlink reaches it.
What this changes
- Add an optional pruneHiddenDirectories walk option. It defaults to
false and is omitted from the wire when disabled.
- Return hidden directory entries, but do not traverse them or add their
canonical identities to the visited set.
- Cover the visible-symlink-to-hidden-directory case through both local
and remote filesystem implementations.
This is the small filesystem prerequisite for #31566. Skill-specific
behavior remains in that PR.
## Description
This PR adds a `codex-extension-items` crate for extension-owned
`TurnItem` schemas, and updates standalone image generation to start
using it via `TurnItem::Extension`.
This gives us a way to prevent Core from having to be aware of all
extension items. App-server still exposes the existing public
`ThreadItem::ImageGeneration` shape, now by wrapping the same shared
`image_generation::ImageGenerationItem` type.
The new `codex-extension-items` crate is necessary because the image gen
extension item is used by:
- `codex-image-generation-extension`, which produces it.
- `codex-tools / core`, which carry it generically.
- `codex-protocol`, which serializes it into lifecycle events and
rollouts.
- `app-server protocol`, which wraps it in public
`ThreadItem::ImageGeneration`
```
extension implementation
↓
codex-extension-items
↓
protocol / tools / app-server
```
We keep the hosted Responses API image generation as
`TurnItem::ImageGeneration` because core still owns its persistence and
legacy fanout.
### Before
Standalone image generation is implemented as an extension, but its item
representation previously lived in the core protocol. This sets the
precedent that core is aware of all extension items, which would be good
to avoid.
```
image-gen extension
→ constructs codex_protocol::ImageGenerationItem
→ emits ExtensionTurnItem::ImageGeneration
→ core matches ImageGeneration specially
→ protocol stores TurnItem::ImageGeneration
```
### After
```
image-gen extension
→ constructs extension-owned ImageGenerationItem
→ emits generic ExtensionItem
→ core transports/persists it generically
→ app-server wraps ImageGenerationItem as ThreadItem::ImageGeneration
```
Future extension items can have typed app-server APIs without adding a
new `TurnItem` variant, `ExtensionTurnItem` variant, or core emitter
match arm.
## What changed
- Added `codex-extension-items` with the closed `ExtensionItem` enum and
shared `image_generation::ImageGenerationItem` schema.
- Added generic `TurnItem::Extension(ExtensionItem)` and
`ExtensionTurnItem::Extension { item, legacy_events }` paths.
- Updated standalone image generation to emit a typed extension item and
provide its existing legacy `ImageGenerationBegin` /
`ImageGenerationEnd` events explicitly.
- Kept canonical lifecycle ordering: core emits `ItemStarted` /
`ItemCompleted` before extension-provided legacy events.
## Follow-up
Standalone web search still uses its typed special-case path. Migrating
it later would let `ExtensionTurnItem` collapse into a single
extension-item struct.
## Why
The V8 Windows source jobs need a runner image that can support the
later Dev Drive setup.
## What
Move the two V8 Windows source-build matrix entries from `windows-2022`
to `windows-2025`.
Namespace the canary source-build cache by runner image so it cannot
restore Windows 2022 native outputs.
## Manual validation
- Ran `just fmt`.
- Ran `just test-github-scripts` (33 tests).
- Parsed GitHub Actions YAML with `yq`.
- Ran `git diff --check`.
## Stack
- [#31332](https://github.com/openai/codex/pull/31332) — parameterize
Cargo target paths
- [#31356](https://github.com/openai/codex/pull/31356) — Windows 2025
runner bump
- [#31357](https://github.com/openai/codex/pull/31357) — Dev Drive I/O
routing
Adds a single trace span around configured hook command execution so
slow installed hooks are visible directly in traces.
The span records low-cardinality hook metadata and command outcome
without command text, hook input, stdout, or stderr.
## Summary
External auth had two paths: provider-command credentials were resolved
through `ExternalAuth`, while app-provided ChatGPT credentials were
installed separately and only used the provider for refresh.
`ExternalAuth` also declared an auth mode independently from the
`CodexAuth` value it returned, so the declaration and credentials could
disagree.
This change makes the provider-owned `CodexAuth` authoritative for
initial resolution, credential kind, and refresh.
- remove `ExternalAuth::auth_mode` and require providers to return their
current auth from `resolve`
- route external auth registration, resolution, and unauthorized refresh
through `AuthManager::set_external_auth`
- keep the last resolved credential with its provider so synchronous
consumers and unauthorized recovery observe the credential's actual mode
- make the app-server bridge own both initial and refreshed ChatGPT
credentials, and detach it on logout
- keep model listing free of auth-refresh side effects, including in
offline mode
Provider-command auth still follows its configured cache interval.
App-provided ChatGPT auth still asks the parent app once after a `401`
and retries the request once.
Stacked on #31355.
## Testing
- `just test -p codex-login`
- `just test -p codex-models-manager`
- focused `codex-app-server` tests for external login/logout,
unauthorized refresh, and workspace mismatch
## Why
Prepare CI jobs for a later build-output relocation without changing
where they write today.
## What
- Export `CARGO_TARGET_DIR` from `setup-ci` at the existing
`codex-rs/target` path.
- Route nextest, release, artifact, and signing paths through
`CARGO_TARGET_DIR`.
- Require V8 staging callers to pass an explicit target directory while
preserving the existing upstream path.
## Manual validation
- Ran `just test-github-scripts`.
- Parsed GitHub Actions YAML with `yq`.
## Stack
- [#31332](https://github.com/openai/codex/pull/31332) — parameterize
Cargo target paths
- [#31356](https://github.com/openai/codex/pull/31356) — Windows 2025
runner bump
- [#31357](https://github.com/openai/codex/pull/31357) — Dev Drive I/O
routing
## Summary
Opening `/review` and choosing a branch currently enumerates branches
through `git branch`, which performs broader branch presentation work.
In a large repo, it isn't hard for this to timeout completely.
This PR instead uses `git for-each-ref` scoped directly to `refs/heads`
so the picker reads only local branch refs. It preserves the existing
sorting and default-branch promotion while excluding remote-tracking
refs and detached-HEAD display rows.
## Summary
- Rename the hosted web-search wire field to the canonical
`indexed_web_access` spelling.
- Preserve existing indexed-search behavior.
## Rollout
Merge and release only after server support for `indexed_web_access` is
fully deployed.
## Testing
- `just fmt`
- `just test -p codex-tools
web_search_tool_spec_serializes_expected_wire_shape`
- Blocking CI passed, including indexed web-search integration coverage.
## Why
Loading skills from a remote executor can add a lot to thread start time
when there are many skills. Previous changes added some concurrency for
the file reads themselves, but we're still bottlenecked on the initial
root path discovery.
Using the benchmark from
[#31295](https://github.com/openai/codex/pull/31295), this change
reduces the measured mean of loading 66 skills about 71%. Behavioral
coverage lands separately in
[#31369](https://github.com/openai/codex/pull/31369).
## What
- resolve the scanned root's inherited namespace once
- resolve discovered nested plugin roots once, retaining
nearest-valid-ancestor behavior
- pass an explicit resolved Plain / Plugin namespace into skill parsing
instead of probing per skill
- preserve explicitly provided plugin namespaces as the highest-priority
source
- reuse the same resolver for environment skills, deleting its duplicate
root-probe and ancestor-selection path
## Validation
- just test -p codex-core-skills namespace: 12 passed on both the parent
and optimized branches
## Why
#31335 lets HTTP callers obtain proxy-aware clients from
`HttpClientFactory`, but a non-HTTP transport such as WebSockets also
needs two pieces of policy owned by `codex-http-client`: a concrete
route decision for its destination and the same custom-CA-aware rustls
trust configuration used by HTTPS.
Keeping these prerequisites in the shared abstraction means the
dependent Responses WebSocket change (#31441) cannot independently
reinterpret `features.respect_system_proxy`, PAC results, or enterprise
CA settings.
## What changed
- Add a redaction-safe `OutboundProxyRoute` with explicit
transport-default, direct, and concrete-proxy outcomes.
- Add `HttpClientFactory::resolve_proxy_route()` so transports can
resolve a destination through the already-selected outbound proxy
policy.
- Resolve `ws://` and `wss://` URLs through their HTTP equivalents so
system and PAC rules apply consistently.
- Add an always-returned rustls config builder that starts from native
roots and layers in any configured Codex custom CA bundle. The existing
optional builder remains available to callers that can delegate the
default configuration to their transport.
- Continue redacting proxy URLs from `Debug` output because they may
contain credentials.
## Review guide
1. `http-client/src/outbound_proxy.rs` defines the transport-neutral
route result and WebSocket URL normalization.
2. `http-client/src/custom_ca.rs` factors the native-root/custom-CA
construction so callers that perform TLS themselves can always obtain a
config.
3. `http-client/src/outbound_proxy_tests.rs` verifies WebSocket
normalization and legacy transport-default behavior.
## Test plan
- `just test -p codex-http-client outbound_proxy`
- `just test -p codex-http-client custom_ca`
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/31342).
* #31431
* #31363
* #31362
* #31361
* #31442
* #31441
* __->__ #31342
## Why
Test callers need one composable way to create app-server fixtures
instead of a growing family of overlapping constructor implementations.
## What
- add a feature-complete TestAppServer::builder()
- make the default builder own a temporary CODEX_HOME and select the
automatic test environment
- expose builder knobs for no automatic environment, explicit
CODEX_HOME, program, arguments, plugin startup tasks, environment
overrides, managed config, and JSON logging
- keep the existing public constructor surface, but route every
constructor through the builder so the new path is exercised immediately
- remove the redundant private constructor ladders; caller migration and
public constructor removal live in the optional cleanup stack
## Validation
- just test -p codex-app-server (940/941 before updating the expected
builder error wording)
- just test -p codex-app-server
auto_env_rejects_explicit_environment_config
- just fix -p codex-app-server
- just fmt
## Follow-up stacks
Cleanup, optional for the benchmark work:
1. [#31451 test: migrate TestAppServer callers to
builder](https://github.com/openai/codex/pull/31451)
2. [#31452 test: remove TestAppServer
constructors](https://github.com/openai/codex/pull/31452)
Benchmark infrastructure:
1. [#31427 test: add delayed exec-server
transport](https://github.com/openai/codex/pull/31427)
2. [#31295 bench: add cold skill load
macrobenchmark](https://github.com/openai/codex/pull/31295)
3. [#31428 bench: add e2e benchmark
entrypoints](https://github.com/openai/codex/pull/31428)
4. [#31429 ci: smoke Bazel e2e
benchmarks](https://github.com/openai/codex/pull/31429)
## Summary
Autocomplete completion previously inserted a new space even when a
separator was already present, which could leave redundant whitespace
around neighboring text. Popup dismissal also tracked only the query
string, so dismissing one token could suppress a different occurrence
with the same text.
This gives completions one horizontal-separator policy across files,
images, skills, and mentions. Existing separators are reused when
possible, ordinary suffix text remains separated, and line breaks stay
intact. Dismissal now identifies the complete whitespace-delimited token
occurrence, so offset-only edits preserve dismissal while later
identical tokens remain independent. Newly completed values beginning
with `$` or `@` can also remain closed when the next PR's affinity rule
recognizes the token to the left of the cursor.
## Examples
The examples below use `|` to represent the cursor.
### Reuse existing separators
Starting with an existing two-space gap:
```text
@ma| next
```
After accepting `src/main.rs` and typing `foo`, completion previously
added a third separator and left both original spaces before `next`:
```text
src/main.rs foo| next
```
After this PR, completion reuses the first existing separator as the
insertion point and preserves the second between the new text and
`next`:
```text
src/main.rs foo| next
```
### Keep a completed sigil-prefixed value closed
Starting before a line break:
```text
@ma|
next
```
and accepting a path whose result is itself prefixed with `@` produces:
```text
@scope/main.rs |
next
```
Without this PR's completion dismissal, the affinity rule in #30463
rediscovers the completed token to the left of the cursor and reopens
its popup:
```text
@scope/main.rs |
^^^^^^^^^^^^^^^ popup reopens
next
```
With this PR, the inserted occurrence is dismissed and the popup remains
closed:
```text
@scope/main.rs |
^^^^^^^^^^^^^^^ popup remains closed
next
```
### Do not dismiss an identical later occurrence
Given two identical tokens:
```text
@scope/main.rs| @scope/main.rs
```
after dismissing the first popup with Escape and moving to the second
token, query-only dismissal previously suppressed the second popup too:
```text
@scope/main.rs @scope/main.rs|
^^^^^^^^^^^^^ popup remains closed
```
After this PR, dismissal also matches the token's ordinal among complete
tokens, so the second occurrence opens normally:
```text
@scope/main.rs @scope/main.rs|
^^^^^^^^^^^^^ popup opens
```
### Keep dismissal across offset-only edits
After dismissing `@ma`, moving to its start, and pasting an email-like
token:
```text
email@ma.com @ma|
```
the `@ma` bytes embedded in `email@ma.com` do not count as another
autocomplete token. The original `@ma` keeps its dismissal even though
its byte range moved.
## Stack
This is PR 2 of 3, stacked on #31190. It relies on the explicit
replacement ranges introduced there and provides the completion
lifecycle used by the targeting fix in #30463.
## Summary
- recognize embedded HTTP(S) URL prefixes case-insensitively in Windows
dangerous-command detection
- add regression coverage for uppercase and mixed-case schemes inside
`Start-Process` invocations
## Why
PowerShell and URL parsing treat schemes case-insensitively, but the
pre-parser only searched for lowercase `http://` and `https://`. When a
URL appeared in the same shlex token as surrounding PowerShell syntax,
such as `Start-Process('HTTPS://example.com');`, the prefix was not
stripped and the command was incorrectly classified as not dangerous.
Validated with the scoped `codex-shell-command` suite (138 tests) and a
direct classifier reproduction that failed before the change and passed
afterward.
## Why
Pre-sampling compaction intentionally uses the previous turn's model
when the compaction compatibility hash changes or when switching to a
model with a smaller context window. This keeps compaction aligned with
the settings that produced the history, but it can block the next turn
when a resumed ChatGPT thread still references a model slug that has
since been retired. The Codex backend rejects that compaction request
before the user's currently selected model gets a chance to sample.
This PR lets those threads recover without changing previous-model
compaction behavior for API-key authentication or custom providers. It
is stacked on #31316, which is a behavior-preserving extraction of the
individual remote compaction attempts; this PR contains the fallback
behavior.
## What changed
- For automatic previous-model compaction, capture the selected model's
request context when using ChatGPT authentication with the OpenAI
provider and the selected model differs from the previous model.
- If the previous-model attempt returns an `InvalidRequest`, retry
compaction once with the selected model for both `/responses/compact`
and Responses Compaction V2.
- Complete history processing, lifecycle events, and token accounting
with the context of the model that successfully compacted the thread.
- If the fallback also fails, return the original previous-model error
so the retry does not change the user-visible failure.
- Record fallback attempts with reason, implementation, and outcome
telemetry.
- Leave API-key authentication, custom providers, same-model turns, and
non-`InvalidRequest` failures on their existing paths.
## Testing
- `just test -p codex-core -E 'test(pre_sampling_compact) |
test(model_unavailable_error)'` (10 tests)
- Added integration coverage for a resumed thread whose model was
renamed, a model downshift using Responses Compaction V2, and API-key
authentication with a custom provider.
This PR depends on [#31296](https://github.com/openai/codex/pull/31296)
for the canonical-to-legacy event mappings.
## Description
This PR makes the v1 and v2 wait paths emit canonical
`TurnItem::CollabAgentToolCall` lifecycle instead of
`CollabWaitingBegin` / `CollabWaitingEnd` directly.
Both paths already used the same legacy waiting events before this PR.
The v1 item carries receiver metadata and final agent statuses for its
target agents; v2 waits for mailbox activity rather than specific
agents, so it keeps those fields empty, matching the existing v2 legacy
payload.
App-server v2 consumes the canonical item directly and ignores the
mapped legacy wait events.
## Why
Wait is separate from the other collab tools because it is multi-target
and has distinct timeout/status behavior. Keeping it last also lets this
PR remove the old helper that only existed to shape legacy wait status
entries in core.
## What changed
- Emit canonical collab wait items from both v1 and v2 wait handlers.
- Preserve receiver metadata and agent status snapshots on completed
wait items.
- Remove the old core helper for building legacy wait status entries.
## Follow-up
The next stack PR, [#30188](https://github.com/openai/codex/pull/30188),
writes canonical `TurnItem` values to paginated rollout files.
This PR depends on [#31296](https://github.com/openai/codex/pull/31296)
for the canonical-to-legacy event mappings.
## Description
This PR makes the non-wait v1 collaboration tools—spawn, send input,
resume, and close—emit canonical `TurnItem::CollabAgentToolCall`
lifecycle instead of their legacy begin/end events directly.
App-server v2 consumes the canonical collab items directly, ignores the
mapped legacy events, and applies close-agent thread-watch cleanup from
the completed item.
## Why
These four tools share the same single-target lifecycle shape. Wait
stays separate because it carries multi-target status snapshots and has
its own status-shaping cleanup.
## What changed
- Add shared helpers for emitting canonical collab tool-call lifecycle.
- Migrate spawn, send input, resume, and close handlers.
- Move close-agent watcher cleanup onto canonical completed collab
items.
## Why
The backend config-bundle contract now exposes managed configuration in
`managed_layers`, split into `baseline` and `system_overlay`. The Rust
transport models need to match that contract before any runtime behavior
changes.
## What changed
- add the generated `DeliveredManagedLayers` model
- model `baseline` and `system_overlay` as required arrays
- expose optional/null `managed_layers` on delivered config and
requirements documents
- retain `enterprise_managed` for transport compatibility
This PR changes transport types only; cloud-config runtime behavior is
unchanged.
## Stack
1 of 4. Next: #31286.
## Validation
- `just test -p codex-backend-openapi-models -p codex-backend-client`
- `just test -p codex-cloud-config`
- revalidated against the current generated backend schema
This PR depends on [#31296](https://github.com/openai/codex/pull/31296)
for the canonical-to-legacy event mappings.
## Description
This PR makes the MultiAgentV2 spawn, message/follow-up, and interrupt
paths emit completed canonical `TurnItem::SubAgentActivity` items
instead of `SubAgentActivityEvent` directly.
App-server v2 now applies interrupted-agent thread-watch cleanup from
the canonical completed item and ignores the mapped legacy activity
event.
## Why
Sub-agent activity is separate from the v1 collab tool begin/end
lifecycle. Keeping it separate makes the v2 watcher side effect
reviewable without mixing in the larger collab tool-call migration.
## What changed
- Emit canonical sub-agent activity items from v2 spawn,
message/follow-up, and interrupt paths.
- Move missing-thread watcher cleanup onto canonical completed activity
items.
- Update focused app-server coverage to exercise canonical interrupted
activity.
## Why
This PR is a behavior-preserving refactor only. It does not add a
fallback, change which model is used for compaction, or otherwise change
compaction behavior. The behavioral change is implemented in the stacked
follow-up, #30319.
Pre-sampling compaction deliberately uses the previous turn's context
when the compaction compatibility hash changes or when switching to a
model with a smaller context window. That preserves the model settings
that produced the history being compacted, but the previous context is
not always usable. For example, a resumed thread can still reference a
model slug that has since been retired, causing compaction to fail
before the currently selected model can sample.
#30319 addresses that failure mode by retrying compaction with the
current turn's selected model when the backend rejects the
previous-model attempt. This PR performs only that preparatory refactor.
## What changed
- Extracted one legacy `/responses/compact` request attempt into
`compact_remote_request.rs`.
- Extracted one Responses-based remote compaction request attempt into
`compact_remote_v2_attempt.rs`.
- Kept hooks, lifecycle events, analytics, window advancement, history
processing and installation, and error behavior unchanged in the
existing orchestration paths.
- Preserved standalone Responses-based compaction's owned client-session
lifetime through lifecycle completion.
## Testing
- `just test -p codex-core -E 'test(remote_compact)'` (22 tests)
## What
Adds an optional hosted login-success redirect path for app-server login
requests.
- Keeps the existing localhost success page as the default.
- Lets app-server callers opt into a hosted success page with an
optional protocol field.
- Persists credentials before redirecting to the hosted success page.
- Keeps org setup and existing CLI/device-code login flows on the local
success page.
- Accepts an optional typed `appBrand` value and forwards it to the
hosted page as `app_brand` so web can select the correct asset.
- Generates the app-server protocol schema updates for the new optional
fields.
## Why
This supports the hosted Codex login success page rollout without
changing existing login behavior by default. The Codex Apps frontend can
gate the opt-in with Statsig after the hosted web page.
## Rollout safety
- Old callers omit the new field and continue using localhost.
- New callers talking to old app-server builds remain safe because the
Codex Apps side treats the field as optional and defaults the flag off.
- Missing brand values default to Codex.
- The hosted redirect always uses the app-login source so the hosted
page can reopen Codex; the existing streamlined-login visual flag
remains separate.
## Validation
- `just fmt`
- `just fix -p codex-login -p codex-app-server-protocol -p
codex-app-server -p codex-app-server-test-client -p codex-tui`
- `just test -p codex-login`
- `just test -p codex-app-server-protocol`
- `just write-app-server-schema`
- `git diff HEAD --check`
The focused login and protocol run passed all 380 tests.
I also started the broader `just test -p codex-app-server`; it compiled
successfully, then many tests failed on this machine because spawned
test servers tried to use the ambient `/Users/rafaelj/.codex/sqlite`
state DB, which is read-only in this sandbox. I stopped that run after
confirming the failures shared that environment issue.
## Summary
- enable `auth_elicitation` by default
- promote the feature to `Stable`, as default-enabled features must be
stable
- update the feature regression test to cover the new lifecycle state
and default
## Impact
Auth elicitation is now available without requiring users or clients to
opt in through configuration.
## Testing
- `just test -p codex-features` (52 passed)
## Why
Approval guidance is currently assembled entirely by the client. Model
Messages V2 needs model catalogs to provide model-specific `on_request`
guidance for both user-reviewed and auto-reviewed approval flows while
retaining the existing generated prompt as a compatibility fallback.
## What changed
- add nullable `on_request` and `on_request_auto_review` catalog
messages
- select the message matching the active approvals reviewer for
`on_request` policies
- replace the complete legacy approval section when the selected catalog
value exists, including support for an empty string that suppresses the
section
- retain legacy rendering when the object or selected key is absent, and
for non-`on_request` policies
- preserve approval messages when base-instruction or personality
overrides clear instruction templates
- refresh permissions instructions when the active model changes
- pass catalog messages through initial and incremental permissions
construction
## Relationship to reviewer persistence
PR #31309 independently persists the approvals reviewer in turn context
and refreshes permissions when that reviewer changes. This PR is based
directly on `main` and does not duplicate that rollout migration; once
both land, reviewer switches will also select and append the new catalog
variant.
## Testing
- `just test -p codex-protocol`
- `just test -p codex-prompts`
- `just test -p codex-models-manager`
- `just test -p codex-core permissions_messages`
## Summary
- measure successful legacy `app/list` latency with
`codex.apps.installed.duration_ms`, segmented by `path=legacy` and
`reload`
- measure successful host-owned `codex_apps` startup and explicit
refresh latency with `codex.apps.refresh.duration_ms`
- add the refresh trigger to successful
`codex.mcp.tools.fetch_uncached.duration_ms` samples for `codex_apps`
without changing other MCP-server samples
## Why
This establishes a small latency baseline for the current connector path
before `ConnectorRuntimeManager`, `app/installed`, and `app/read` land.
Error-rate and broader runtime-state instrumentation are intentionally
deferred.
This is telemetry-only and does not change connector behavior.
## Validation
- `just test -p codex-mcp` (94 passed)
- `just test -p codex-app-server list_apps` (13 passed)
- `just fix -p codex-mcp`
- `just fix -p codex-app-server`
- `just fmt`
- `git diff --check`
## Summary
- Treat streamed Responses `bio_policy` failures as terminal invalid
requests instead of retryable stream errors.
- Recognize the new biology policy code and message in the TUI while
preserving the legacy `invalid_prompt` contract.
- Keep the existing dedicated biology safety notice and add
regression/snapshot coverage for all supported error shapes.
## Why
[openai/openai#1068559](https://github.com/openai/openai/pull/1068559)
gates a Responses API contract change from `invalid_prompt` and the
legacy message to `bio_policy` and new biology copy.
Without this compatibility change, streamed blocks are retried as
transient failures and the OSS TUI falls back to a generic/raw error
instead of the dedicated safety notice.
## Validation
- `just test -p codex-api` — 137 passed
- `just test -p codex-tui
app_server_safety_access_errors_render_dedicated_notice` — passed
- `just fix -p codex-api`
- `just fix -p codex-tui`
- `just fmt`
- `just test -p codex-tui` — 2,957 passed; two reproducible failures
remain in untouched Guardian feature-flag persistence tests:
-
`update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default`
-
`update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history`
## Summary
- Adds `writes` to `AppToolApproval` and exposes it through config and
app-server schemas, including
`[apps._default].default_tools_approval_mode`.
- In `writes`, tools with `readOnlyHint = true` skip approval; all other
tools prompt, including non-destructive writes and tools without
annotations.
- Prevents session or persistent approval choices in this mode so later
writes still prompt.
## Why
`auto` only prompts for risk-hinted actions, while `prompt` also
interrupts reads. Apps need a middle mode that gates writes without
prompting for declared read-only actions.
## Validation
- `just write-config-schema`
- `just write-app-server-schema`
- `just fmt`
- `just test -p codex-core mcp_turn_metadata` (4 passed)
- `just test -p codex-core writes_mode` (2 passed)
- `just test -p codex-app-server config_read_includes_apps` (1 passed)
- `just test -p codex-app-server-protocol` (251 passed)
- `just test -p codex-config` (200 passed)
- `just test -p codex-cli` (300 passed)
- `just fix -p codex-core -p codex-config -p codex-app-server-protocol
-p codex-app-server -p codex-cli`
## Why
Windows Bazel test shards currently cap local test actions at 4.
Controlled forced-test-execution measurements in #31339 found that 8
local jobs reduced Bazel elapsed time on every shard by 19–29%,
including the slow shard from 835.5s to 609.3s, while 12 jobs regressed.
## What
Set `common:ci-windows-cross --local_test_jobs=8` in `.bazelrc`.
## Manual validation
- `git diff --check`
- `just fmt`
- [8-job CI
experiment](https://github.com/openai/codex/actions/runs/28838387129)
## Summary
- refactor `ExternalAuth` to return `CodexAuth` directly
- remove the parallel `ExternalAuthTokens` wrapper
- preserve existing external bearer and app-server refresh behavior
This is a mechanical precursor refactor; it does not add auth
capabilities or change recovery behavior.
## Testing
- `cargo fmt --all`
- `cargo test -q -p codex-login --lib`
- `cargo test -q -p codex-app-server --test all
external_auth_refreshes_on_unauthorized`
## Why
Intel macOS release binaries crash on the first Code Mode tool call
while V8 creates its code range. The x86_64 V8 allocator later makes a
non-`MAP_JIT` reservation executable, which Hardened Runtime rejects
when the signature contains only `com.apple.security.cs.allow-jit`.
Tracks
[SE-8006](https://linear.app/openai/issue/SE-8006/intel-macos-codex-cli-crashes-in-v8-startup-on-gpt-56-sol-tool-calls).
Fixes#28390.
## What
- add an expanded entitlement profile only for x86_64 `codex` and
`codex-app-server`, the release binaries that link V8
- keep arm64 and `codex-responses-api-proxy` on the existing narrower
profile
- share one fail-closed target/binary selector between signing and final
verification
- verify the expected Mach-O architecture and exact entitlement
dictionary for the signed binary, tar.gz, zstd, package, and DMG copies
## Verification
- `just test-github-scripts` (34 tests)
- `UV_CACHE_DIR=/private/tmp/codex-uv-cache just fmt-check`
- `bash -n .github/scripts/macos-signing/select_codex_entitlements.sh`
- `plutil -lint` on both entitlement profiles
- parsed `rust-release.yml` as YAML
- `git diff --check`
- ad-hoc Hardened Runtime signing smoke on an x86_64 Mach-O slice:
strict `codesign` verification passed; the Codex profile contained
exactly both keys and the proxy profile retained exactly `allow-jit`
## Release validation
Run a native Intel smoke of the final Developer ID-signed x86_64 Codex
binary through V8 isolate creation before shipping. PR #30849 is
diagnostic scaffolding, but its non-sandbox release job currently fails
in the harness before V8 starts, so it is not counted as coverage here.
## Why
Before changing plugin namespace loading performance, lock down the
existing behavior so the same cases can be validated before and after
the optimization.
## What
- cover mixed plain and nested plugin skills under one scan root
- cover inherited, nested, and invalid-manifest namespace precedence
- cover symlinked plugin skill directories, symlinked plain directories,
and scan-root ancestor symlinks
## Validation
- just test -p codex-core-skills namespace on unmodified main: 12 passed
This PR depends on [#31296](https://github.com/openai/codex/pull/31296)
for the canonical-to-legacy event mappings.
## Description
This PR makes dynamic tools emit canonical `TurnItem::DynamicToolCall`
lifecycle instead of `DynamicToolCallRequest` /
`DynamicToolCallResponse` directly.
App-server v2 now sends the client `DynamicToolCall` request from the
canonical item start. It ignores the mapped legacy request/response
events, so clients receive one item start and one tool request.
## Why
Dynamic tools are a separate migration boundary because their start
event also drives a client request. Keeping that routing change isolated
makes it easier to verify that the request still happens exactly once.
## What changed
- Emit in-progress and completed/failed dynamic tool items from the
dynamic tool handler.
- Move app-server client request dispatch onto canonical dynamic item
starts.
- Add focused app-server coverage for the canonical start notification
and client request.
This PR depends on [#31296](https://github.com/openai/codex/pull/31296)
for the canonical-to-legacy event mappings.
## Description
This PR makes command execution emit canonical
`TurnItem::CommandExecution` lifecycle from both the shell tool path and
user `/shell` commands.
App-server v2 consumes the canonical command items directly and ignores
the mapped `ExecCommandBegin` / `ExecCommandEnd` compatibility events,
so clients still receive one command item lifecycle.
`UnifiedExecInteraction` stays on the legacy path because
`TerminalInteraction` is still the v2 surface for stdin and poll events.
Emitting a command item there would render the same wait twice.
## Why
This is the first live producer migration after the compatibility
mappings in #31296. Keeping command execution separate makes the unified
exec exception reviewable without mixing in dynamic tools or multi-agent
behavior.
## What changed
- Emit canonical command execution items from shell tool events and user
shell commands.
- Preserve the existing unified exec interaction carveout.
- Move app-server command deduplication and completion bookkeeping onto
canonical item events.
- Update unified exec coverage to assert the completed command item.
## Why
Users can see that usage-limit reset credits are available, but not
which credits they have, when each one expires, or which credit will be
consumed. The TUI should use the supported rate-limit RPC for that
information without maintaining a second reset-credit request path.
## What changed
- load reset-credit details through the existing
`account/rateLimits/read` refresh when the user opens **Redeem usage
limit reset**
- show available credits sorted by expiry, using the backend title when
present and a scope-based fallback otherwise
- consume the exact selected credit and preserve its idempotency key
across retries
- fall back to the existing generic reset action when the RPC returns a
positive count without detail rows
- remove the dedicated list-RPC event, request, response-combining, and
TUI state plumbing
- handle a selected credit becoming unavailable without incorrectly
caching the user's total count as zero
- handle forward-compatible unknown reset types with the existing
scope-based fallback label
## TUI preview
Rendered from the final standard-width and narrow `insta` snapshots in
this PR.
<img width="1280" height="570" alt="pr30488-reset-picker-preview"
src="https://github.com/user-attachments/assets/8b84cd33-cb35-4a37-aaed-dbd6b62bff51"
/>
## Validation
- `just test -p codex-tui chatwidget::tests::usage` (32 passed)
- `just fix -p codex-tui`
- no pending `insta` snapshots
Uses the reset-credit details added by #30395.
Fixes#29618.
[Codex Thread
019edd6d-6f14-74e2-853c-345d1803d4a6](https://codex-thread-link.openai.chatgpt-team.site/thread/019edd6d-6f14-74e2-853c-345d1803d4a6)
## Stack
Review and merge in order. Every layer is independently correct and
documents its safe stopping point.
1. [openai/codex#30292](https://github.com/openai/codex/pull/30292) —
aggregate File/Secrets store locking
2. [openai/codex#30293](https://github.com/openai/codex/pull/30293) —
resolve and lifecycle-pin the exact OAuth store
3. [openai/codex#30416](https://github.com/openai/codex/pull/30416) —
serialized authoritative refresh transaction
4. [openai/codex#30294](https://github.com/openai/codex/pull/30294) —
Codex-owned transport refresh and one-shot 401 recovery
5. [openai/codex#30295](https://github.com/openai/codex/pull/30295) —
login/logout transaction serialization
6. [openai/codex#30296](https://github.com/openai/codex/pull/30296) —
diagnostic-only Auto store drift reporting
**This PR is layer 1.**
## Why
MCP OAuth credentials stored in File or Secrets share one aggregate map.
Concurrent read-modify-write operations for different MCP servers can
both read the same snapshot and let the later write discard the earlier
update. That is a correctness problem independent of refresh-token
rotation.
## What this PR does
- Adds a bounded cross-process lock around aggregate File and Secrets
loads, saves, and deletes.
- Distinguishes aggregate-lock failures from Secrets backend
unavailability, so Auto can fall back only for the latter and cannot
bypass serialization by reading or writing File.
- Keeps Direct keyring operations outside this lock because they are
already per credential.
- Releases the Secrets aggregate lock before legacy File cleanup so
cross-store cleanup cannot create nested aggregate-lock ordering.
- Tests actual contention by waiting for an observed `WouldBlock`,
rather than assuming a sleeping worker reached the lock.
- Tests load and save with only the Secrets lock path broken while
fallback File remains readable and writable.
## Decisions and non-goals
- This lock protects aggregate-store read-modify-write integrity only.
It does not choose a credential authority or serialize an OAuth refresh
transaction.
- The lock is scoped to the active `CODEX_HOME`, matching the aggregate
files it protects.
- Lock waits are bounded, and coordination failures are surfaced rather
than treated as evidence that Secrets is unavailable.
## Safe stopping point
This PR can merge alone. It prevents lost updates and partial aggregate
reads. Auto can still resolve again during a client lifecycle until
layer 2, and concurrent refreshes remain possible until layer 3.
## Validation
- `just test -p codex-rmcp-client` (96 passed; expected environment
skips)
- Focused aggregate File/Secrets lock contention and Auto fallback tests
## Why
`features.respect_system_proxy` already routes authentication traffic
through the OS proxy APIs, but it does not affect the primary inference
path. That leaves users behind OS-managed proxies unable to send normal
Responses API requests even after login succeeds.
This PR is the first product-path migration onto the route-aware
transport introduced in #31323 and refined in #31331. It also
establishes the construction pattern for later migrations: the effective
feature state is resolved once into a required HTTP client factory
rather than represented by an optional per-call setting.
The scope remains limited to the two HTTP Responses endpoints;
WebSockets, model discovery, memories, realtime, and file uploads remain
follow-up migrations.
## What changed
- Replace the optional proxy marker with an explicit
`OutboundProxyPolicy::{ReqwestDefault, RespectSystemProxy}` and a
required `HttpClientFactory`. The policy has no default, and the
lower-level route-aware reqwest builder is now private.
- Have `Config` construct the factory from the effective feature state
and require every `ModelClient` constructor to receive it. There is no
optional setter or implicit `None` fallback.
- Build HTTP clients for `/responses` and `/responses/compact` with
`ClientRouteClass::Api`, using the complete destination URL so PAC rules
can make URL-specific decisions.
- Layer route-aware selection onto Codex's existing default headers,
Cloudflare cookie store, custom CA handling, and sandbox no-proxy
behavior.
- Add an integration test that loads `features.respect_system_proxy`
through `config.toml`, creates a real Codex session, and verifies that
both a normal Responses turn and remote compaction reach an isolated
local proxy.
## Review guide
1. `http-client/src/outbound_proxy.rs` defines the mandatory
policy/factory boundary and keeps route resolution private.
2. `core/src/config/mod.rs`, `core/src/session/session.rs`, and
`core/src/client.rs` show the compile-time invariant: effective config
creates the factory, and `ModelClient` cannot be constructed without
one.
3. `login/src/auth/default_client.rs` preserves existing default-client
behavior while accepting the required factory for migrated routes.
4. `core/src/client.rs` switches only streaming Responses and remote
compaction HTTP transports to the API route class.
5. `core/tests/suite/responses_api_system_proxy.rs` is the behavioral
regression boundary. Its Linux subprocess deliberately sets the CGI
marker that disables reqwest's implicit environment-proxy handling, so
the test fails if session wiring or either Responses call site falls
back to the default client.
## Test plan
- `cargo check --tests -p codex-http-client -p codex-login -p
codex-core`
- `just test -p codex-login`
- `just test -p codex-core
respect_system_proxy_feature_resolves_enabled`
- Existing `compact_uses_bearer_after_agent_identity_session_fallback`
coverage passes with the new transport construction.
- New Linux integration coverage:
`responses_and_compact_use_enabled_system_proxy`
- `just bazel-lock-check`
---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/31335).
* #31342
* __->__ #31335
## Description
This PR adds legacy `EventMsg` mappings for the `TurnItem` types
introduced in [#30282](https://github.com/openai/codex/pull/30282):
- `CommandExecution`
- `DynamicToolCall`
- `CollabAgentToolCall`
- `SubAgentActivity`
When their producers move to canonical `ItemStarted` / `ItemCompleted`,
raw core event consumers can still receive the existing begin/end-style
events. The canonical item lifecycle remains the live source of truth.
We also record the mapped legacy events in rollout trace so the producer
migration preserves the existing tool-runtime trace entries.
## Why
This is the compatibility layer for the follow-up producer migrations.
Splitting it out first keeps each producer PR small and keeps the legacy
mapping in one place.
## What changed
- Added `TurnItem` → legacy `EventMsg` mappings in
`protocol/src/legacy_events.rs`.
- Added the command execution status conversion used by the exec
mapping.
- Added focused coverage for command execution and dynamic tool
mappings.
## Why
`fragmented_writes_yield_to_keepalive_and_queued_pong` deliberately
blocks WebSocket writes while exercising keepalive and queued-Pong
scheduling. It previously advanced those states with wall-clock sleeps.
Under a sufficiently delayed CI worker, those sleeps and scheduling gaps
could consume the test-only 100 ms Pong-watchdog budget, causing the
relay to exit and the next write-permit send to fail with
`TrySendError::Disconnected`.
The failure was therefore a timing flake in the harness test, not
evidence that the production relay mishandled a Pong.
## What changed
- Run this test with Tokio time paused.
- Advance the virtual clock through its two keepalive transitions
instead of sleeping in wall-clock time.
- Enable Tokio's `test-util` feature only for `codex-exec-server` dev
dependencies.
No production code or timeout values change.
## Review guide
The behavioral change is confined to `noise_relay/harness_tests.rs`; the
`Cargo.toml` change only exposes Tokio's paused-clock test APIs.
## Validation
- `just test -p codex-exec-server
fragmented_writes_yield_to_keepalive_and_queued_pong`
- `just fix -p codex-exec-server`
- `just bazel-lock-update` (no lockfile changes)
## Summary
When enabled for the OpenAI provider, Codex sends
`stream_options.reasoning_summary_delivery = "sequential_cutoff"` on
HTTP and
WebSocket requests, including prewarm, and renders completed summary
sections
from `reasoning_summary_text.done`. Flag-off and non-OpenAI behavior is
unchanged.
## Expected rollout
```text
reasoning 0 added
summary 0 done
summary 1 done
summary 2 starts
summary 2 cancelled / incomplete
reasoning 0 done <-- cancel summary 2 work and mark it incomplete
message 1 added
message 1 text streams
message 1 completed
```
Depends on
[openai/openai#1096660](https://github.com/openai/openai/pull/1096660).
## Why
Cleanup for #31179 exposed a core fallback bug that the TUI had been
handling locally. When a custom `.rules` file fails to parse, nonfatal
clients warn and continue, but `load_exec_policy_with_warning` replaced
the entire policy with `Policy::empty()` before managed requirements
were merged. App-server and desktop clients could therefore silently
lose required prompt and forbidden rules.
This fix is intentionally separate from #31179 so the TUI cleanup does
not depend on it.
## What changed
- Preserve the managed requirements exec policy when custom file rules
fail to parse, while returning the existing warning and discarding the
file-based policy.
- Use the same nonfatal fallback when loading network proxy policy.
- Keep parse errors fatal for strict clients such as `codex exec`.
