Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window.
Resume reconstruction derives window 0 state from that initial_window_id when no compaction window metadata exists. Fork reconstruction ignores copied parent session_meta.context_window values so the fork keeps its own fresh initial window id, and legacy compactions without window_number continue to use compaction-count fallback accounting.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-core reconstruct_history_preserves_legacy_compaction_count_with_session_meta_window
- just test -p codex-core record_initial_history_forked_ignores_parent_session_meta_window
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just test -p codex-rollout persistence_metrics
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
- just fix -p codex-core -p codex-rollout
## Summary
- replace the stale `AskForApproval::OnFailure` reference in the MCP
connection manager test with `AskForApproval::OnRequest`
- restore `codex-mcp` test compilation after `OnFailure` was removed in
#28418
## Root cause
The test was added on main after the approval-policy removal branch had
already updated the other references, so the newly added call site was
missed when #28418 merged.
## Validation
- `just test -p codex-mcp` (90 passed)
- `just fmt`
## Why
view_image needs to support foreign OS remote executors.
## What
- resolve image paths against the selected environment as `PathUri` and
read them through that environment's filesystem
- keep app-server's public path field wire-compatible as
`LegacyAppPathString`, with purpose-specific UI rendering
- cover relative and absolute target-native paths in the core
integration test and run the full `view_image` suite under wine-exec
without skips
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window. Resume reconstruction derives window 0 state from that initial window_id and still prefers compacted window metadata once compaction records exist.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
## Summary
- allow the native Responses API `image_generation` tool when the active
provider carries CCA's non-empty `x-openai-actor-authorization` header
- preserve the Codex-managed ChatGPT auth path, scoped to providers that
actually require OpenAI auth
- keep generic custom providers excluded, including when unrelated
ChatGPT credentials are cached
- retain the existing feature, provider-capability, and
image-input-modality gates
## Why
CCA authenticates its inference requests through the active provider's
`x-openai-actor-authorization` and `ChatGPT-Account-ID` headers, so it
does not have a Codex-managed login session. The previous gate therefore
hid the native hosted image-generation tool despite an authenticated
codex-backend path.
This change is intentionally limited to the native hosted tool. It adds
no extension, MCP, plugin-service, session-source, token plumbing, or
new provider configuration surface.
## Tests
- `cargo test -p codex-core
hosted_tools_follow_provider_auth_model_and_config_gates`
- `cargo fmt --all -- --check`
- `git diff --check origin/main`
## Why
Filesystem helpers intentionally run with a minimal environment that
excludes proxy variables. After filesystem operations started using the
Windows sandbox wrapper, the wrapper derived an empty proxy
configuration from that helper environment and compared it with the
persistent sandbox setup marker. When the marker contained proxy ports,
every filesystem operation appeared to require a firewall update, which
could launch elevated setup, show a UAC or loader dialog, and fail
operations such as `apply_patch` with error 1223.
Filesystem helpers do not use network access, so they should preserve
the proxy/firewall state established by normal sandboxed process
launches.
## What changed
- Add an explicit Windows sandbox proxy-settings mode for reconciling or
preserving persistent proxy state.
- Use preserve mode for filesystem helpers while normal process launches
continue to reconcile proxy settings from their environment.
- Carry the selected proxy state consistently through setup validation,
elevated setup, and non-elevated ACL refreshes.
- Cover wrapper argument propagation and marker-derived proxy
preservation.
## Validation
- `cargo build -p codex-cli --bin codex`
- `just test -p codex-windows-sandbox
preserving_proxy_settings_uses_the_existing_marker`
- `just test -p codex-windows-sandbox windows_wrapper_args_round_trip`
- `just test -p codex-windows-sandbox
setup_request_prefers_explicit_proxy_settings`
- `just test -p codex-sandboxing transform_for_direct_spawn_windows`
- `just test -p codex-exec-server fs_sandbox::tests`
- Ran the same sandboxed `fs/writeFile` reproduction against published
`0.142.0-alpha.6` and the new CLI. The published CLI launched elevated
setup and failed with `ShellExecuteExW ... 1223`; the new CLI completed
without elevation.
Related to #28359.
## Why
Plugin analytics overloaded `plugin_id`: most events used the Codex
`<plugin>@<marketplace>` identity, while remote install events used the
backend plugin ID. That makes the same field change meaning across event
types and complicates downstream identity resolution.
This change makes the contract unambiguous:
- `plugin_id`: the local Codex `<plugin>@<marketplace>` identity, when
resolved
- `remote_plugin_id`: the backend plugin identity, when available
For a remote install failure that happens before plugin details resolve,
`plugin_id` is `null` and `remote_plugin_id` remains populated.
## What changed
All six plugin analytics events use the same identity contract:
- `codex_plugin_installed`
- `codex_plugin_install_failed`
- `codex_plugin_uninstalled`
- `codex_plugin_enabled`
- `codex_plugin_disabled`
- `codex_plugin_used`
Remote identity is resolved from the current installed-plugin snapshot
first, with persisted install metadata as fallback. The telemetry
metadata type keeps local identity optional for failures that occur
before remote details are available.
The app-server test client's manual analytics smokes now find remote
mutation events through `remote_plugin_id` and validate that `plugin_id`
remains local.
## Remote uninstall
Resolve and capture telemetry metadata before removing the local plugin
cache, then emit `codex_plugin_uninstalled` after the backend confirms
success. The event is also emitted when backend uninstall succeeds but
local cache cleanup reports `CacheRemove`.
If a concurrent remote-cache refresh removes the local bundle before
telemetry capture, the already-fetched remote plugin detail supplies
fallback capability metadata.
## Validation
- `just test -p codex-analytics` — 82 passed
- `just test -p codex-core-plugins` — 271 passed
- `just test -p codex-app-server-test-client` — 5 passed
- `just test -p codex-plugin` — 3 passed
- `just test -p codex-app-server plugin_install` — 37 passed
- `just test -p codex-app-server plugin_uninstall` — 10 passed
The production app-server install/uninstall flow was also exercised
against `plugins~Plugin_f1b845ac33888191ac156169c58733c2`
(`build-ios-apps@openai-curated-remote`), and the plugin's original
uninstalled state was restored.
## Why
The managed MITM trust bundle must be readable by sandboxed commands.
Persisting its sibling CA private key under `$CODEX_HOME/proxy`
therefore requires a deny-read sandbox rule, but the Windows unelevated
backend rejects deny-read paths and WSL1's legacy Landlock path cannot
enforce that rule.
A persistent OS credential store also does not provide the same
cross-platform boundary from other processes running as the same user.
Keeping the signer inside the network proxy process avoids both
problems: ordinary sandbox setup stays independent of CA-key state, and
no private signing key is exposed through the filesystem or a persistent
credential record.
## What
- generate one managed CA per proxy process and retain its private
signer only in proxy memory
- emit only content-addressed public CA certificates and trust bundles
under `$CODEX_HOME/proxy`
- hold a cross-process lease for each active public certificate and
prune artifacts from inactive proxy processes
- keep all CA ownership in `codex-network-proxy`; no `codex-core` or
sandbox-policy changes
- validate generated trust-bundle paths by their content hash
- keep the public bundle readable by sandboxed commands on Windows,
WSL1, macOS, and Linux
The independent startup custom-CA follow-up is #29014.
## Validation
- `CODEX_HOME=/private/tmp/codex-test-home-network-proxy just test -p
codex-network-proxy` (179 tests)
- `just bazel-lock-check`
- `just fix -p codex-network-proxy`
- `just fmt`
---------
Co-authored-by: viyatb-oai <viyatb@openai.com>
## Why
Managed network configures commands to use local HTTP and SOCKS proxies.
For commands delegated to the exec server, the proxy environment and the
sandbox policy were prepared separately. On macOS, that meant a command
could receive `HTTPS_PROXY=http://127.0.0.1:43123` while Seatbelt still
denied access to port `43123`.
## What changed
`NetworkProxy` now prepares the command environment and sandbox context
together from the same runtime snapshot:
```text
Prepared managed network
├── command environment: HTTPS_PROXY=http://127.0.0.1:43123
└── sandbox context: allow outbound to 127.0.0.1:43123
```
That context travels with remote exec requests. The exec server
preserves the managed proxy and CA environment, and macOS Seatbelt
allows only the prepared loopback proxy ports without enabling broad
network access or local binding.
The protocol field is optional and the existing enforcement flag remains
in place, preserving compatibility with callers that do not send the new
context.
## Why
The rollout persistence metrics added on current `main` exhaustively
match `ResponseItem`, but omit `ResponseItem::AdditionalTools`. That
prevents `codex-rollout` and downstream targets from compiling across
Cargo and Bazel builds.
## What
Map `ResponseItem::AdditionalTools` to the `response.additional_tools`
metric label, consistent with the existing exact-variant labels.
## Validation
- `just test -p codex-rollout` (76 passed)
- `just fix -p codex-rollout`
## Summary
Handle `ResponseItem::AdditionalTools` in rollout persistence metrics.
The persistence metrics match was added after the `AdditionalTools`
variant and omitted it, causing release builds to fail with a
non-exhaustive pattern error. This assigns the item the
`response.additional_tools` metrics label.
Release failure:
https://github.com/openai/codex/actions/runs/28043786727/job/83016608475
## Validation
- `just fmt`
- `just test -p codex-rollout` (76 passed)
## Why
Follow-up to #29249 and its [compaction review
thread](https://github.com/openai/codex/pull/29249#discussion_r3455055101).
During a turn, environment readiness can change between sampling
requests. Inline compaction must render the same model-visible
`WorldState` used by the request it follows. Rebuilding that state
during compaction can observe a newer environment, make replacement
history disagree with what the model saw, and suppress the next
environment update.
## What changed
- Make `run_turn` own the current `Arc<WorldState>` and replace it only
between sampling requests.
- Build each state from an explicitly chosen environment snapshot, diff
deferred-executor steps against the turn-owned state, and retain the
latest state in `ContextManager` only for cross-turn and resume
tracking.
- Pass the exact turn-owned state into inline compaction and explicit
new-context-window replacement.
- Carry that state with
`InitialContextInjection::BeforeLastUserMessage`, so replacement context
and its stored baseline cannot come from different snapshots.
- Remove obsolete state-recapture helpers and ambiguous TurnContext-only
WorldState builders.
- Add an integration test that moves an environment from starting to
ready during a paused turn, triggers compaction, and verifies the next
request receives the readiness update exactly once.
## Test plan
- `just test -p codex-core
deferred_executor_compaction_preserves_then_updates_environment_once`
- `just test -p codex-core process_compacted_history`
- `just test -p codex-core mid_turn_continuation_compaction`
- `just test -p codex-core build_initial_context`
- `just test -p codex-core
ignores_session_prefix_messages_when_truncating`
## Summary
MCP refresh replaced the published connection manager without shutting
down the manager it superseded. If another task retained that old
manager, its stdio MCP processes stayed alive and accumulated across
refreshes.
Atomically swap in the refreshed manager, then explicitly shut down the
exact manager returned by the swap. Add a process-level regression test
that retains the old manager during refresh and verifies its stdio
process exits while the replacement remains available.
## Context
Explicit cleanup was lost when manager publication moved to `ArcSwap`.
Dropping the old manager is not a reliable shutdown boundary because
active callers can retain its `Arc` and underlying client process
handles.
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window. Resume reconstruction derives window 0 state from that initial window_id and still prefers compacted window metadata once compaction records exist.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
Record the initial AutoCompactWindowIds window_id in session_meta.context_window so JSONL tailers can observe the first context window before any compaction item exists. Thread creation now requires an initial_window_id string, while rollout JSONL keeps that value under the context_window namespace without writing derived chain fields for the initial window. Resume reconstruction derives window 0 state from that initial window_id and still prefers compacted window metadata once compaction records exist.
Verification:
- just test -p codex-protocol
- just test -p codex-rollout recorder_materializes_on_flush_with_pending_items
- just test -p codex-core reconstruct_history_restores_initial_window_from_session_meta
- just test -p codex-core reconstruct_history_prefers_compacted_window_over_session_meta
- just test -p codex-thread-store
- just test -p codex-state
- just test -p codex-app-server thread_read_returns_summary_without_turns
- just fix -p codex-protocol -p codex-rollout -p codex-thread-store -p codex-core -p codex-app-server
## Summary
- rename `reminder_interval_model_requests` to
`reminder_interval_seconds`
- read the configured time provider before every model request and
inject a reminder only after the configured number of seconds has
elapsed
- preserve immediate first delivery and forced delivery after compaction
changes the context window
## Tests
- `just test -p codex-core current_time_reminder`
Michael Bolin