checkpoint: into wallentx/termux-target from release/0.141.0 @ 28fe11ec54f0 - #234
Merged
wallentx merged 76 commits intoJun 16, 2026
Conversation
## Summary Prevent dependency refreshes from silently downgrading Codex's bundled SQLite to a release affected by the WAL-reset corruption bug. SQLx 0.9 accepts a broad `libsqlite3-sys` range. An unrelated lock refresh therefore moved Codex from `libsqlite3-sys 0.37.0` back to `0.35.0`, changing the bundled SQLite runtime from 3.51.3 to 3.50.2. SQLite documents the affected versions and fix in [The WAL Reset Bug](https://www.sqlite.org/wal.html#the_wal_reset_bug) and the [SQLite 3.51.3 changelog](https://www.sqlite.org/changes.html#version_3_51_3).
## Intent Keep Bazel and Starlark files consistently formatted without requiring contributors to install or version buildifier themselves. ## Implementation - Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier v8.5.1. - Run buildifier from the shared `just fmt` and `just fmt-check` driver, with Windows-safe explicit DotSlash invocation. - Provision DotSlash in formatting CI and contributor devcontainers, and document the source-build prerequisite. - Apply the initial mechanical buildifier formatting baseline.
## Why Cross-OS tests in the wine environment will be much more faithful if we can also test powershell integration. ## What Add an x86_64 powershell binary to the bazel wine environment and include smoke tests.
## Why We're moving to `PathUri` in more places to support cross-OS app-server/exec-server, but we don't want to expose the URI encoding to users of app-server's public APIs yet. We'll need to translate at the app-server API boundary between client-visible "regular" paths that are appropriate for the OS of the environment for which the paths make sense, which means using the environment's path personality to do the conversion. `PathUri` doesn't yet attempt to encode environment ID, so for now we'll sniff the most likely path convention for a given path. ## What - Add `PathConvention` and `NativePathString` with host-independent POSIX, Windows drive, and UNC rendering. - Cover cross-host rendering, encoding, Unicode, invalid components.
…8122) ## Why Next slice needed to make progress on the `remote_env_windows` test is to support passing a Windows cwd for the remote environment and using that environment's native shell. This lets the test run a real Windows process instead of only recording an early path or shell mismatch. ## What - change `TurnEnvironmentSelection.cwd` from `AbsolutePathBuf` to `PathUri` - convert local cwd values to URIs when constructing selections - preserve a remote primary cwd instead of replacing it with the local legacy fallback - prefer the selected environment's discovered shell for unified exec, falling back to the session shell when unavailable - convert back to a host-native absolute path at current native-only consumer boundaries - reject or deny unsupported foreign cwd values at the existing request-permissions boundary, with TODOs for its future migration - extend the hermetic Wine test to execute Windows PowerShell in `C:\windows` and verify successful process completion - record the current app-server rejection against the same Wine-backed remote Windows fixture when its cwd is supplied as a native Windows path
## Why Clients that display or coordinate spawned subagents need an authoritative snapshot of a thread's immediate spawned children when they connect to app-server or recover after missing live events. `thread/list` cannot query by parent, so clients must otherwise scan unrelated threads or reconstruct relationships from rollout history and transient events. The direct spawn relationship already exists in persisted `thread_spawn_edges` state. Review and Guardian threads do not participate in that lifecycle and are intentionally outside this filter's scope. ## What changed This adds an experimental `parentThreadId` filter to `thread/list`. Parent-filtered requests return direct spawned children from persisted state while preserving the existing response shape, explicit filters, sorting, and timestamp-only cursor behavior. The lookup does not read rollout transcripts or recursively return descendants. Supersedes openai#25112 with the narrower `thread/list` filter approach. ## How it works 1. An experimental client passes a valid thread ID as `parentThreadId`. 2. App-server routes the list through the existing thread-store and state-database boundaries. 3. SQLite selects threads whose IDs have a direct persisted spawn edge from that parent. 4. Omitted provider and source filters include all values; explicit filters keep ordinary `thread/list` semantics. 5. Grandchildren, Review threads, and Guardian threads are excluded. ## Verification State (144 tests), rollout (69 tests), and focused app-server thread-list (31 tests) suites passed. Scoped Clippy checks and repository formatting also passed. Coverage includes direct spawned children, omitted grandchildren, pagination, malformed IDs, mixed source kinds, explicit filters, and operation without rollout files.
…enai#27884) ## Why **In short:** this PR resolves already-discovered MCP registrations. It does not read selected plugins or discover their MCP servers. The resolved MCP catalog currently builds config and auto-discovered plugin registrations before runtime contributors are applied. A thread-selected plugin needs a distinct precedence tier in that same initial resolution pass: otherwise a disabled lower-precedence winner can leave stale name-level state behind, and the winning MCP tools cannot be attributed to the selected package reliably. This PR adds that catalog boundary before executor discovery is connected. ## What changed - Added an explicit selected-plugin registration tier between auto-discovered plugins and explicit config. - Collected selected-plugin contributions before the initial catalog build, while leaving compatibility and generic extension overlays in their existing runtime phase. - Retained the winning plugin ID and display name directly on plugin-owned catalog registrations. - Derived MCP tool provenance from the winning catalog entry instead of joining against local-only plugin summaries. - Retained the winning selected server's tool approval policy in the running connection manager, so a selected registration cannot inherit approval behavior from a losing local plugin. - Kept remembered approval session-scoped for selected plugins until there is an authority-aware persistence contract; Codex will not write approval back to an unrelated local plugin. - Preserved existing name-level disabled vetoes for discovered plugins and config, while keeping a selected package's own disabled registration scoped to that registration. - Preserved deterministic selection order and existing config, compatibility, and extension precedence. The resulting order is: ```text auto-discovered plugin < selected plugin < explicit config < compatibility registration < extension overlay ``` ## Behavior and scope This is a catalog and provenance change only. No production host contributes selected-plugin MCP registrations yet, so existing local MCP behavior remains unchanged. The stacked follow-up, openai#27870, installs the executor plugin provider that produces these registrations. App-server activation remains a separate final step. ## Verification Focused tests cover precedence, deterministic selected-plugin conflicts, disabled-veto behavior across catalog phases, managed requirements before selected-plugin resolution, winning-server approval policy, and attribution when local and selected packages share an ID or server name. CI owns execution of the test suite.
## Why **In short:** this PR discovers MCP registrations by reading a selected plugin's `.mcp.json` on its executor. openai#27884 then resolves those registrations in the shared catalog. `thread/start.selectedCapabilityRoots` can select a plugin root owned by an executor, and Codex can resolve that package through the executor filesystem. MCP declarations inside the selected plugin are still ignored. This PR adds the source-specific discovery layer on top of the selected-plugin catalog boundary in openai#27884: ```text selected capability root | v resolve the plugin through its executor filesystem | v read and normalize its MCP config through the same filesystem | v contribute stdio registrations bound to that environment ID ``` The existing MCP launcher and connection manager remain unchanged. MCP config parsing is shared with local plugins through openai#27863. ## What changed - Added an executor plugin MCP provider in the MCP extension. - Retained only the exact filesystem capability used for package resolution and reused it for the selected plugin's MCP config, with no host-filesystem fallback or unrelated process/HTTP authority. - Read either the manifest-declared MCP config or the default `.mcp.json`; a missing default file means the plugin has no MCP servers. - Accepted stdio servers only for this first vertical. Executor-owned HTTP declarations are skipped with a warning until their placement semantics are defined. - Normalized stdio registrations with the owning environment's stable logical ID and plugin-root working directory. - Resolved environment-variable names on the owning executor and rejected explicit local forwarding for non-local plugins. - Froze discovered declarations once per active thread runtime, then applied current managed plugin and MCP requirements when contributing them. - Carried the selected root ID, display name, and selection order into the catalog contribution defined by openai#27884. ## Behavior and scope There is intentionally no production behavior change yet. This PR provides the executor provider and contribution boundary, but app-server does not install it in this change. Existing local plugin MCP loading is unchanged, and no MCP process is launched by this PR alone. ## Assumptions - The selected root ID is the plugin policy identity; the manifest display name is presentation metadata. - An environment ID is a stable logical authority. Reconnection or replacement under the same ID does not change ownership. - Selected plugin packages and their manifests are trusted inputs. - The selected package and MCP discovery snapshot remain frozen for the active thread runtime. ## Follow-up The next PR installs this contributor in app-server and adds an end-to-end test proving that a selected plugin MCP tool launches on its owning executor, can be called by the model, survives an explicit MCP refresh, and is invisible when its root was not selected. Resume, fork, environment removal or ID changes, dynamic catalog reload, and executor-owned HTTP MCP placement remain separate lifecycle decisions. ## Verification Focused tests cover executor-only filesystem reads, missing and malformed config, stdio filtering and normalization, managed requirements, package attribution, and selection order. CI owns execution of the test suite.
## Summary - align the default multi-agent v2 root and subagent hints with the evaluated prompt guidance for direct collaboration-tool calls, parallel delegation, and shared workspaces - keep the current `interrupt_agent` tool name and existing concurrency-hint placement, with the explicit no-spawn instruction last - document the context tradeoff between `fork_turns="none"` and `fork_turns="all"` in the v2 `spawn_agent` description - extend the focused prompt and tool-surface tests ## Why The evaluated multi-agent prompt includes operational guidance that is missing from the current Codex defaults. This applies that guidance to the current tool surface without restoring stale `close_agent` or duplicated concurrency wording. ## User impact Multi-agent v2 receives clearer instructions about when and how to parallelize work, how agent workspaces interact, and how `fork_turns` affects subagent context. The existing default opt-out behavior remains in place. ## Testing - `just fmt` - `just test -p codex-core multi_agent_v2_default_usage_hints_use_configured_thread_cap` - `just test -p codex-core multi_agent_feature_selects_one_agent_tool_family`
## Context This is PR4 in the plugin auth-routing stack. The earlier PRs make plugin surface projection auth-aware and narrow App/MCP conflicts by App declaration name. This PR keeps connector listing paths aligned with that projected plugin App set. This means ChatGPT/SIWC users will still see plugin-provided Apps in connector listing surfaces like the Apps/connector picker, while API-key users will not see Apps they cannot use. ## Stack - PR1: openai#27652 seed plugin manager auth at construction. - PR2: openai#27459 route plugin surfaces by auth mode. - PR3: openai#27607 dedupe plugin MCP servers by App declaration name. - PR4: openai#27602 preserve plugin Apps in connector listings. - PR5: openai#27461 skip install-time plugin MCP OAuth for matching App routes. ## Summary - Have app-server compute effective plugin Apps from the existing PluginsManager and pass them into connector listing. - Keep plugin Apps visible in Apps/connector listing for ChatGPT/SIWC users. - Keep API-key-style auth from surfacing plugin Apps in connector listings. ## Validation ```bash cargo test -p codex-chatgpt connectors::tests cargo test -p codex-app-server list_apps_includes_plugin_apps_for_chatgpt_auth git diff --check ```
## Context This is PR5 in the plugin auth-routing stack. Earlier PRs make plugin surface projection auth-aware, narrow App/MCP conflicts by App declaration name, and keep connector listings auth-aware. This PR applies the same name-based App/MCP conflict rule into plugin MCP loading, so install-time MCP OAuth and plugin detail metadata both reflect the MCPs available for the current auth route. ## Stack - PR1: openai#27652 seed plugin manager auth at construction. - PR2: openai#27459 route plugin surfaces by auth mode. - PR3: openai#27607 dedupe plugin MCP servers by App declaration name. - PR4: openai#27602 preserve plugin Apps in connector listings. - PR5: openai#27461 skip install-time plugin MCP OAuth for matching App routes. ## Summary - Make `load_plugin_mcp_servers` auth-aware and let it load App declarations before filtering same-name MCP servers for Codex-backend auth. - Use that filtered MCP list for both install-time MCP OAuth and marketplace plugin detail metadata. - Preserve API-key/direct auth behavior so plugin MCP servers remain visible and can still start OAuth. ## Validation ```bash cargo fmt --all cargo test -p codex-core-plugins read_plugin_for_config_filters_mcp_servers_for_codex_backend_auth cargo check -p codex-core-plugins -p codex-app-server git diff --check git diff --cached --check ```
## Why openai#27870 teaches the MCP extension how to discover stdio MCP servers declared by a selected executor plugin, but app-server does not yet install that contributor or initialize its per-thread state. As a result, `thread/start.selectedCapabilityRoots` can select the plugin while its MCP servers remain inactive. This PR closes that app-server wiring gap: ```text thread/start(selectedCapabilityRoots) -> initialize the thread's selected-plugin MCP snapshot -> read the selected plugin's .mcp.json through its environment -> start declared stdio servers in that environment -> expose their tools only on the selected thread ``` ## What changed - Install the selected-executor-plugin MCP contributor in app-server using the existing shared `EnvironmentManager`. - Initialize its frozen thread snapshot when `thread/start` includes selected capability roots. - Document that selected plugin stdio MCPs are activated in their owning environment. - Add an app-server E2E covering the complete selection-to-tool-call path. The E2E verifies that: - the selected MCP process receives an executor-only environment value, proving the tool runs through the selected environment; - the MCP tool is advertised to the model and can be called; - a normal MCP config reload does not discard the thread's frozen selected-plugin registration; - another thread without the selected root does not see the MCP server. ## Scope - Existing sessions without `selectedCapabilityRoots` are unchanged. - Only stdio MCP declarations are activated. HTTP declarations remain inactive. - This does not change selected-root persistence across resume/fork or add hosted-plugin behavior. ## Verification - Focused app-server E2E: `selected_executor_plugin_exposes_its_stdio_mcp_only_to_that_thread` ## Stack Stacked on openai#27870.
## Summary - cap feedback log uploads to at most eight threads before SQLite log aggregation and rollout attachment resolution - keep the root session included while bounding descendant fanout during `/feedback` uploads ## Why Very large sessions can accumulate large spawned-thread subtrees. Feedback uploads currently walk the entire subtree and then read each resolved rollout into memory, which can blow up when one session has hundreds of descendants. ## Validation - ran `just fmt` - did not run tests or Clippy per request; CI will cover validation
…7365) Follow-up to openai#27356. ## Stack note This PR changes Codex's internal dynamic-tool shape while leaving `thread/start` unchanged. App-server therefore converts the existing per-tool input into explicit functions and namespaces before passing it to core. [openai#27371](openai#27371) updates `thread/start` to use the same explicit shape and removes this temporary conversion. ## Why Dynamic tools repeat namespace metadata on every function. Core should keep one explicit namespace with its member tools so descriptions and membership stay consistent across sessions and runtime planning. ## What changed - Represent dynamic tools as top-level functions or explicit namespaces in protocol and session state. - Read old flat rollout metadata and write the canonical hierarchy. - Flatten namespace members only when registering callable tools. - Keep `thread/start.dynamicTools` flat for now and normalize it at the app-server boundary. New builds can read old rollout metadata. Older builds cannot read newly written hierarchical metadata. ## Test plan - `just test -p codex-app-server thread_start_normalizes_legacy_dynamic_tools_into_model_request` - `just test -p codex-protocol session_meta_normalizes_legacy_dynamic_tools` - `just test -p codex-core resume_restores_dynamic_tools_from_rollout_with_sqlite_enabled` - `just test -p codex-core tool_search_returns_deferred_dynamic_tool_and_routes_follow_up_call` - `just test -p codex-core code_mode_can_call_hidden_dynamic_tools` - `just test -p codex-tools`
## Why App-server threads without a local executor need orchestrator-owned skills from the hosted `codex_apps` MCP server. Threads with the local executor already discover installed skills from the local filesystem. After the orchestrator skill provider was enabled for every app-server thread, local-executor threads also received the hosted skill catalog and the `skills.list` and `skills.read` tools. This changed the existing local behavior and could expose a second hosted copy of a skill that was already installed locally. ## What changed - Expose the thread's selected execution environments to extensions at thread startup. - Enable orchestrator skills only when the reserved local environment is not selected. - Apply that decision consistently to hosted skill catalog discovery, explicit skill injection, and the `skills.list` and `skills.read` tools. ## Verification - The existing no-executor app-server test continues to verify hosted skill discovery, invocation, and child-resource reads. - A new app-server test verifies that local-executor threads do not receive hosted skill context or `skills.*` tools.
## Why Shell snapshot lifecycle state was split between `Shell` and `SessionServices`: `Shell` carried the receiver while session code exposed and forwarded the raw sender. That coupled shell identity to mutable snapshot state and made refresh, inheritance, and file lifetime harder to reason about. ## What changed - make each `Arc<ShellSnapshot>` represent one cwd-specific snapshot generation - store the active generation in `SessionServices` with `ArcSwapOption` - have construction start the background build and expose only a cwd-validated snapshot path - use `ShellSnapshotFile` ownership to delete snapshot files automatically - pass snapshot paths explicitly to shell runtimes instead of storing snapshot state on `Shell` - preserve inherited and in-flight generations by pinning their `Arc` while they are in use ## Test plan - `cargo check -p codex-core --lib` - `just test -p codex-core 'shell_snapshot::tests'` - `just test -p codex-core shell_command_snapshot_still_intercepts_apply_patch` - `just test -p codex-core shell_snapshot_deleted_after_shutdown_with_skills`
## Why `terminal_resize_reflow` is now stable and should behave as always on. Keeping the disabled runtime paths around made the feature look configurable even though the rollout is complete, and old config could still suggest there was a supported off mode. ## What Changed - Marked `terminal_resize_reflow` as `Stage::Removed` while keeping it default-enabled for compatibility. - Ignored `[features].terminal_resize_reflow` config entries so stale `false` settings no longer affect the effective feature set. - Removed TUI branches that depended on the flag being disabled, so draw, replay buffering, stream finalization, and resize scheduling all assume resize reflow is active. - Simplified resize smoke coverage to exercise the always-on behavior only. ## Verification - `just test -p codex-features` - `just test -p codex-tui resize_reflow` - `just test -p codex-tui initial_replay_buffer thread_switch_replay_buffer`
## Why The ws pump refactor removed the relay keepalive timers that had been added to keep idle rendezvous connections alive. An idle relay could therefore be closed by the rendezvous service or a load balancer, disconnecting executor-backed MCP processes. ## What - restore periodic WebSocket ping frames on both rendezvous relay endpoints - keep missed-tick behavior bounded with `MissedTickBehavior::Skip` - cover the harness and remote-environment pumps with focused traffic-after-keepalive tests
## Why Memory read telemetry currently reconstructs the executable shell command after a tool call finishes. That duplicates shell, login-policy, and cwd resolution owned by the tool handlers, and can diverge from the environment-specific command that unified exec actually ran. ## What changed - Expose the existing restricted shell-script parser directly for raw script text. - Parse `shell_command` and `exec_command` input into plain command argv before classifying memory reads. - Preserve all-or-nothing safe-command validation for multi-command scripts. - Remove cwd resolution, shell selection, and the unnecessary async boundary from memory read metric emission. ## Testing - `just test -p codex-shell-command` - `cargo check -p codex-core`
Stacked on openai#27365. ## Stack note [openai#27365](openai#27365) kept `thread/start` unchanged and converted its input in `thread_processor`. This PR updates `thread/start` to accept explicit functions and namespaces directly. Legacy per-tool arrays are still accepted and converted while reading the request. As a result, `thread_processor` can validate and pass the tools through directly, which is why some code added in openai#27365 is removed here. ## Why `thread/start.dynamicTools` still repeats namespace data on each function even though core now stores explicit namespace groups. The request API should use the same shape so each namespace has one description and one member list. ## What changed - Accept top-level functions and explicit namespace objects in `dynamicTools`. - Continue accepting fully legacy flat arrays, including `exposeToContext`. - Reject arrays that mix legacy and canonical entries. - Reuse the protocol types directly and remove the temporary app-server adapter. - Update validation, docs, the test client, and generated schemas. ## Test plan - `just test -p codex-app-server-protocol` - `just test -p codex-app-server dynamic_tool_call_round_trip_sends_text_content_items_to_model` - `just test -p codex-app-server thread_start_normalizes_legacy_dynamic_tools_into_model_request` - `just test -p codex-app-server thread_start_rejects_mixed_dynamic_tool_formats` - `just test -p codex-app-server thread_start_rejects_hidden_dynamic_tools_without_namespace`
## Why When we prepare the conversation history, every tool call needs a matching output. Before this change, we scanned the full history again for every call. In a tool-heavy conversation, that makes the work `O(items x calls)`, or `O(n^2)` in the worst case. ## What Scan the history once and collect the IDs of existing outputs. Then each call can check its ID with an expected `O(1)` lookup. The full normalization step is now expected `O(n)`. The output order and missing-output behavior stay the same. ## Performance Based on local rollout traces, one tool-heavy session reached roughly 17,050 transcript items with about 4,292 tool-call items. On a history of that shape, the old `calls x items` scan does about 73.2 million membership checks, while the new pass does about 21.3 thousand set inserts/lookups. That is roughly 3.4k times less membership work in this normalization step. ## Validation - `just test -p codex-core normalize_` (19 passed)
## Why Every model request cloned the full prepared input just to keep it for the legacy after-agent hook. That copy gets more expensive as the conversation grows. ## What Move the prepared input into the sampling loop and return it with the result. If the request retries, keep the first input so the hook still sees the same data as before. This removes one `O(n)` clone per sampling request, where `n` is the size of the prepared input. It saves `O(n)` copy work and `O(n)` temporary memory. No behavior change is intended. ## Performance Local rollout traces show turns reaching roughly 260k input tokens. On turns of that size, this removes the only unconditional full prepared-input clone on the happy path. That avoids one request-sized allocation/copy per sampling attempt for large conversations, and the savings scale linearly with request size. ## Testing - `just test -p codex-core continue_after_stream_error` - `just fix -p codex-core`
## Why Responses WebSocket requests were encoded in two steps: first into a full `serde_json::Value`, then again into the JSON string sent over the socket. That walks the full request twice and keeps an extra JSON tree alive. These requests can contain the complete conversation history and tool schemas, so the extra work grows with the request size. ## What changed - serialize `ResponsesWsRequest` directly to the wire string - pass that string through the existing WebSocket stream and send path - keep the existing error mapping, tracing, send timeout, and telemetry behavior - compare the new wire JSON with the previous `to_value` payload in a focused test ## Performance I measured both paths in an optimized temporary test using a 6,324,180-byte request: 4 MiB of history plus 256 tools with 8 KiB descriptions. Each path ran 100 times. - previous `to_value` + `to_string`: 209 ms total, 2.09 ms per request - direct `to_string`: 174 ms total, 1.74 ms per request - difference: about 17% faster, or 0.35 ms per request The direct path also removes one full temporary `serde_json::Value` tree. For this mostly string-backed payload, that avoids roughly one payload-sized copy plus the JSON node overhead. The exact memory saving depends on the request shape. The temporary benchmark was removed before committing. ## Validation - `just test -p codex-api` — 125 passed - `just fix -p codex-api`
## Why WebSocket continuations only send the new part of a request. Checking whether a request could be continued was cloning the full previous request, the current request, and their input history. For long conversations or large tool lists, that meant copying several request-sized values on every continuation. ## What changed - compare the request settings by reference - check the previous input and server response as borrowed prefixes - allocate only the new input items that will be sent The reuse rules stay the same, including ignoring `client_metadata` for this check. The comparison is still `O(n)`, but it removes several `O(n)` allocations and copies. Temporary memory no longer grows by multiple full request sizes for each continuation. ## Performance Local rollout traces show continuation checks on turns around 260k input tokens. Before this change the reuse gate cloned the previous request, the current request, and the previous input history before deciding whether it could continue incrementally. After this change it borrows those structures and allocates only the incremental tail. For large continuations with a small delta, that removes roughly three request-sized copies from the hot path and reduces temporary memory from multiple full request sizes to just the new tail. ## Validation - `just test -p codex-core responses_websocket_v2_creates_with_previous_response_id_on_prefix` - `just test -p codex-core responses_websocket_v2_creates_without_previous_response_id_when_non_input_fields_change`
## Why `main` fails dev-profile Cargo and Bazel Clippy builds because `core/src/tools/runtimes/mod_tests.rs` imports `PathExt` after its last use was removed. With warnings denied, that stale import prevents `codex-core` test targets from compiling across platforms. ## What changed Remove the unused `PathExt` import. Remaining `.abs()` calls in the module operate on `PathBuf` and continue to use `PathBufExt`. ## Validation - `just fmt` - Focused `codex-core` test compile attempted; blocked locally by disk exhaustion before compilation completed. The CI failure itself is the unused-import diagnostic this change removes.
## Why The generic OTLP HTTP paths for log events and trace events need end-to-end coverage before exec-server relies on them. ## What changed - Adds loopback coverage for exporting `codex_otel.log_only` events to `/v1/logs`. - Verifies `codex_otel.trace_safe` events are present in the exported trace payload. This is a test-only PR. It does not change OTEL runtime behavior or metric APIs. ## Related work - openai#26091: counter descriptions - openai#27057: gauge instruments - openai#27058: second-based duration histograms This PR is independent and can land directly on `main`. ## Validation - `just test -p codex-otel` - `just fix -p codex-otel` - `just fmt`
## Why Responses HTTP requests were converted from `ResponsesApiRequest` into a full `serde_json::Value`. `EndpointSession` then deep-cloned that value for each retry, and the transport serialized and compressed it again before every send. Large histories make those copies expensive. Retry attempts should reuse the same immutable request bytes. ## What - Serialize standard Responses requests directly into a ref-counted `EncodedJsonBody`. - Preserve the Azure path that attaches item IDs before encoding. - Prepare JSON, compression, and derived content headers once before the retry loop. - Clone the prepared request per attempt so body clones only bump the `Bytes` reference count. - Keep auth inside the retry loop. Signing auth sees the exact final headers and body bytes that the transport sends. - Preserve request-body TRACE output. With TRACE plus compression, retain the original JSON bytes for logging; normal requests keep only the final wire bytes. - Leave non-Responses endpoint bodies on the existing `Value` path. ## Performance A temporary release-mode measurement used a 10 MiB JSON body and 10 retry preparations: - old `Value` clone + serialize path: 30 ms total - prepared shared-byte path: less than 1 ms total That is about 3 ms avoided per retry for this payload on the test machine. Each retry also stops allocating another request-sized JSON tree and serialized buffer. Without TRACE, compressed requests retain only the final compressed wire bytes. ## Validation - `just test -p codex-client` — 28 passed - `just test -p codex-api` — 125 passed - `just fix -p codex-client` - `just fix -p codex-api`
## Why `TurnEnvironmentSelections::new` rewrote the primary environment's explicit `cwd` to the legacy fallback cwd. For a remote-first selection, this could replace the remote working directory with a local fallback path and made the legacy cwd overlay authoritative over environment-owned state. ## What changed - Preserve every explicit environment cwd when constructing turn environment selections. - Keep `cwd`-only app-server updates compatible by rebuilding the default environment selections at the requested cwd. - Cover both explicit primary cwd preservation and cwd-only updates reaching the model-visible execution environment. ## Testing - `just test -p codex-core session_update_settings_does_not_rewrite_sticky_environment_cwds` - `just test -p codex-core environment_settings_preserve_explicit_primary_cwd` - `just test -p codex-app-server thread_settings_update_cwd_retargets_default_environment`
## Why Guardian reviews embed the parent session transcript as untrusted evidence. Skill or plugin mentions in that transcript must not be interpreted as requests to inject more instructions into the Guardian request, and memory context adds unrelated model-visible context to an approval decision. Keeping those sources out of the nested review session makes the request smaller and preserves the trust boundary around the transcript being assessed. ## What changed - Skip skill and plugin discovery when building turns for Guardian reviewer sessions. - Disable memory context and dedicated memory tools in the derived Guardian configuration. - Extend the Guardian request-layout coverage to verify that a `$skill` mention remains visible only as transcript evidence while neither the skill body nor memory context is injected. - Expand the Guardian configuration test to cover the disabled memory settings. ## Testing - Updated the Guardian review request snapshot and assertions for skill and memory isolation. - Extended the Guardian session configuration test to cover memories.
This adds the background plumbing for remote-backed plugin catalog sections while leaving the fuller directory presentation to the next PR. The TUI can fetch section-specific remote marketplace results, keep local plugin data available, and carry section errors forward for later rendering. - Fetches explicit remote marketplace kinds for curated, workspace, and shared-with-me sections. - Gates shared-with-me loading on the plugin sharing feature flag. - Adds section-level error state and user-actionable error copy. - Merges remote marketplace results into the cached plugin list without discarding local results.
## Why Selected execution environments are thread-scoped resources, but startup and turn construction repeatedly resolved their IDs and working directories. That discarded existing environment handles and shell metadata even when a selection had not changed. Session configuration updates also need to affect future turns without changing the resolved environment set already captured by a running turn. ## What changed - Create a `ThreadEnvironments` service inside `Codex` from the spawned `EnvironmentManager` and raw environment selections, then store it on `SessionServices`. - Split service construction from `update_selections`, allowing session configuration updates to mutate the resolved set in place. - Retain an existing `TurnEnvironment` when its environment ID and working directory match; resolve only added or changed selections and remove selections that are no longer present. - Normalize duplicate IDs by keeping the first selection and skip individual selections that fail to resolve instead of rejecting the entire update. - Give each `TurnContext` a cloned `TurnEnvironmentSnapshot`, so later session configuration updates affect future turns without rewriting an active turn. - Reuse the service-owned environment manager and resolved snapshot for startup work, MCP initialization, and child-thread spawning instead of flowing resolved environments through spawn arguments. ## Test plan - `cargo check -p codex-core --tests` - `just test -p codex-core environment_selection` - `just test -p codex-core turn_environments` - `just test -p codex-core session_update_settings_does_not_rewrite_sticky_environment_cwds` - `just test -p codex-core default_turn_does_not_overlay_legacy_fallback_cwd_onto_stored_thread_environments`
## Why Realtime voice harness tuning needs app-side control over what backend Codex text is spoken. Backend orchestrator text is written for a reading UI, so automatically speaking every preamble, progress update, or final assistant message can make the realtime voice model too chatty. For experimentation, clients need two simple controls: keep app/client text-item injection on the existing item-create path, and add an explicit speakable path that app code can call only when it wants realtime to speak. Automatic Codex output also needs an opt-in way to switch from the protocol's default speakable path to regular realtime items, with a caller-provided prefix so prompt wording can be tuned outside core. The default remains unchanged: if a client omits the new start fields and never calls `appendSpeech`, automatic backend output continues down the existing speakable path for the selected realtime protocol. ## What Changed - Adds experimental `thread/realtime/appendSpeech` for app-provided speakable text. - Keeps existing `thread/realtime/appendText` as the item-create API for app-provided realtime text items. - Adds `codexResponsesAsItems` / `codex_responses_as_items` on `thread/realtime/start` to send automatic Codex responses with `conversation.item.create` instead of the protocol's default speakable output path. - Adds `codexResponseItemPrefix` / `codex_response_item_prefix` so clients can prepend experiment instructions to those automatic Codex response items. - Keeps literal `conversation.handoff.append` routing scoped to the v1 speakable path; v2 default speech uses its item/function-output plus `response.create` behavior. - Removes the earlier public silent-context API and hardcoded silent-context prefix. - Updates realtime tests to cover default automatic speakable behavior, opt-in automatic item-create behavior, and explicit `appendSpeech` behavior. ## Validation - `cargo check -p codex-core -p codex-app-server -p codex-api` - `just test -p codex-app-server realtime_conversation` - `just test -p codex-core realtime_conversation` (50/51 passed in the filtered parallel run; the lone failure passed when rerun in isolation) - `just test -p codex-core conversation_mirrors_assistant_message_text_to_realtime_handoff` - `just test -p codex-api e2e_connect_and_exchange_events_against_mock_ws_server` - `just fix -p codex-core` - `just fix -p codex-app-server` - `cargo build -p codex-cli`
…7093) ## This PR The original [combined remote plugin analytics PR openai#26281](openai#26281) mixed reusable analytics test infrastructure, two manual smoke workflows, a metadata refactor, and the final identity behavior. This PR isolates the generic capture mechanism so it can be reviewed and landed before any plugin-specific behavior. - Add a debug-only analytics destination that writes final request payloads as JSONL. - Suppress HTTP delivery whenever capture mode is selected, including after capture write failures. - Keep release behavior unchanged even when the capture environment variable is present. - Keep the mechanism generic; this PR contains no plugin-specific behavior. Set `CODEX_ANALYTICS_EVENTS_CAPTURE_FILE=/path/events.jsonl` when running a debug Codex binary to inspect the exact batched payload that would otherwise be sent to the analytics endpoint. ## Testing - `just test -p codex-analytics` (76 passed) - `just test --release -p codex-analytics` (73 passed) - CI is green across the required platform matrix. ## Split Overview ```text main ├── openai#27093 Debug analytics capture ← you are here │ └── openai#27099 Non-mutating plugin smoke │ └── openai#27100 Remote install/uninstall smoke └── openai#27102 Plugin telemetry metadata refactor After openai#27093, openai#27099, openai#27100, and openai#27102 merge: └── Final PR: add remote_plugin_id to plugin analytics ``` Review order and dependencies: 1. [openai#27093 Add debug-only analytics event capture](openai#27093) **(this PR, based on `main`)** 2. [openai#27099 Add a plugin analytics smoke workflow](openai#27099) (stacked on openai#27093) 3. [openai#27100 Add a remote plugin analytics mutation smoke workflow](openai#27100) (stacked on openai#27099) 4. [openai#27102 Centralize plugin telemetry metadata construction](openai#27102) (independent, based on `main`) 5. Final remote-ID behavior PR (created after PRs 1-4 merge) The original [openai#26281](openai#26281) remains open as the green aggregate reference until the final PR is published.
## Why Rendezvous forwards traffic between the orchestrator and exec-server. The endpoints need to authenticate each other and encrypt that traffic without trusting Rendezvous with plaintext or endpoint keys. ## Changes - Adds a hybrid Noise IK channel through Clatter using X25519, ML-KEM-768, AES-256-GCM, and SHA-256. - Binds each handshake to `environment_id`, `executor_registration_id`, and `stream_id`. - Pins the registry-provided executor key and carries the harness authorization inside the encrypted handshake. - Orders relay frames before consuming Noise nonces and fragments large JSON-RPC messages into bounded records. - Bounds handshake payloads, frames, streams, and message reassembly. Runtime activation is in [openai#26245](openai#26245). ## Stack 1. **[openai#26242](openai#26242: Noise channel and relay transport 2. [openai#26245](openai#26245): remote registration and runtime activation ## Verification - `just test -p codex-exec-server` - Oversized initiator payload regression coverage - `just fix -p codex-exec-server` - `just bazel-lock-check` - `cargo shear` --------- Co-authored-by: Codex <noreply@openai.com>
) ## Why Progress towards letting app-server and exec-server run on different platforms, specifically for sandbox configuration. ## What - Make the filesystem path containment hierarchy generic, defaulting to `AbsolutePathBuf` for now. - Have clients specify `AbsolutePathBuf` or `PathUri` directly where needed. - Use `PathUri` throughout exec-server filesystem protocol and trait boundaries. - Implement `From` for conversion to path URIs and `TryFrom` for fallible conversion to absolute paths through the generic type hierarchy.
Summary - Add the two missing `metadata: None` initializers after openai#28355 made response-item metadata required. - Restore test compilation for `codex-core` and `codex-api` on main. Validation - `git diff --check` - `just fmt` (Rust formatting passed; unrelated Python formatter steps could not use the sandboxed shared `uv` cache) - Focused crate tests are running after PR creation.
## Why Exec-server request and connection latencies need fractional-second histograms. The existing duration API records integer milliseconds and uses millisecond-scale buckets. ## What changed - Adds a described duration API that records `Duration` values as fractional seconds. - Uses second-scale explicit histogram boundaries. - Caches duration histograms by name, unit, and description, matching the existing instrument caching model. - Covers exact boundaries, representative bucket placement, fractional sums, and exported metadata. This PR only adds the duration primitive. It does not add exec-server adoption. ## Stack 1. openai#26091: counter descriptions 2. openai#27057: gauge instruments 3. **openai#27058: second-based duration histograms** 4. openai#25019: initialize exec-server OpenTelemetry at startup Related independent coverage: openai#27059 tests OTLP HTTP log and trace event export. ## Validation - `just test -p codex-otel`
## Summary This is the first step in making plugin auth routing consistent. The rule should not live as one-off checks in every place that loads or displays plugin capabilities. This PR introduces a small resolver for the auth-level policy: given a plugin's declared apps, MCP servers, current auth mode, and active state, return the capabilities that are actually usable in that context. ## Why Product rule: - SiWC auth can use app connectors, so app declarations stay available. - API-key/direct auth cannot use app connectors, so app declarations are removed. - When an active plugin has both an app and an MCP server with the same name, the app route wins for Codex-backed auth and the conflicting MCP server is hidden. Putting that rule in `capabilities.rs` gives the rest of the stack one place to ask instead of duplicating auth checks in loader, manager, marketplace, and details code. ## Validation - `cargo fmt` - `cargo test -p codex-core-plugins`
## Summary - Add `includeStartupContext` to realtime start requests so callers can explicitly skip Codex startup context while keeping the backend prompt - Thread the new flag through protocol types, request processing, and realtime session config - Update app-server docs and coverage for the new default and opt-out behavior ## Testing - Added protocol serialization coverage for `includeStartupContext` - Added realtime integration coverage for starting a session with startup context disabled
Addresses openai#26383 and openai#26452 ## Summary `codex exec --dangerously-bypass-hook-trust` printed the bypass warning, but valid untrusted hooks still did not run. Exec applied the flag to its initial config, then lost it when app-server reloaded config for the new or resumed thread. ## Fix Forward `bypass_hook_trust: true` through the existing thread request config override for both start and resume. The override is omitted when the flag is not enabled, preserving normal trust behavior. ## Testing Added: - A test confirming start and resume preserve the override. - An end-to-end exec test confirming a `SessionStart` hook runs and creates a marker file.
…8401) ## Why We want to exercise a linux app-server against a windows exec-server without having to repeat every test case. This approach has slight precedent in the remote docker test setup. ## What Run the shared `codex-core` integration suite against Windows exec-server behavior from Linux. This makes cross-OS path and shell regressions visible while keeping unsupported cases owned by individual tests. - Add `local`, `docker`, and `wine-exec` test environment selection with legacy Docker compatibility. - Extend `codex_rust_crate` to generate a sharded Wine-exec variant using a cross-built Windows server and pinned Bazel Wine/PowerShell runtimes. - Teach remote-aware helpers about Windows paths and track temporary incompatibilities with source-local `skip_if_wine_exec!` calls and follow-up reasons.
## Why The transport in [openai#26242](openai#26242) needs to be used by every remote orchestrator-to-executor connection before JSON-RPC traffic starts. ## Changes - Generates one executor Noise identity when remote exec-server starts and registers its public key. - Creates a harness identity for each physical remote environment connection. - Fetches a fresh registry bundle before connecting and validates the authenticated harness key before completing the executor handshake. - Multiplexes encrypted logical streams over the existing executor WebSocket. - Adds bounded stream, handshake-failure, and reassembly state. - Adds safe lifecycle diagnostics without logging keys, authorizations, plaintext, or ciphertext. - Covers reconnects, replay rejection, validation failure, framing limits, and encrypted JSON-RPC tool traffic. ## Stack 1. [openai#26242](openai#26242): Noise channel and relay transport 2. **[openai#26245](openai#26245: remote registration and runtime activation ## Verification - `just test -p codex-exec-server` - `just fix -p codex-exec-server` - `just bazel-lock-check` - `cargo shear` --------- Co-authored-by: Codex <noreply@openai.com>
## Summary - choose the local OpenAI curated marketplace manifest based on auth: Codex backend auth gets the existing marketplace, direct provider auth gets `api_marketplace.json` - include Bedrock API key auth in the direct-provider API marketplace path - safely skip the API marketplace when `api_marketplace.json` is absent ## Validation - `just fmt` - `git diff --check origin/main...HEAD` - CI should run the full validation ## Manual Testing ### - New api marketplace not available for API key sign 1. Safely not display anything from api marketplace <img width="1161" height="289" alt="Screenshot 2026-06-15 at 21 37 43" src="https://github.com/user-attachments/assets/a5f16642-8a20-4ac1-a0de-1274a4c7b5b2" /> ### - New api marketplace for API key sign in 1. Setup api_marketplace.json ``` { "name": "openai-curated", "interface": { "displayName": "Codex official" }, "plugins": [ { "name": "linear", "source": { "source": "local", "path": "./plugins/linear" }, "policy": { "installation": "AVAILABLE", "authentication": "ON_INSTALL" }, "category": "Productivity" } ] } ``` 2. Log in with API key, observe that only the defined plugin from api_marketplace.json is available from "Codex Official" (outside of local testing marketplaces) <img width="1167" height="446" alt="Screenshot 2026-06-15 at 21 16 53" src="https://github.com/user-attachments/assets/7cf61477-d826-4ef6-bc05-0a23ac1c0259" /> also checked functionality on codex app ### - SiWC users Still uses 'default' marketplace.json and renders all plugins <img width="1171" height="502" alt="Screenshot 2026-06-15 at 21 40 25" src="https://github.com/user-attachments/assets/d212ea9b-0aa5-470b-8ea4-450efe65bb2b" /> also checked functionality on codex app ## Notes - `just test -p codex-core-plugins` was started locally before splitting branches, but I stopped relying on local tests per follow-up and left final validation to PR CI.
## Summary
Makes plugin details/read flows capability-aware so auth-filtered plugin
surfaces report the same usable app/MCP/skill shape as the marketplace
and install flows.
## Validation
Not run; this change was rebased onto the current plugin auth stack and
pushed as a draft PR.
**Manual test**
1. set up a local marketplace with a plugin that has both app and mcp
declarations
```
// .app.json
{
"apps": {
"linear": {
"id": "some_id"
}
}
}
```
```
// .mcp.json
{
"mcpServers": {
"linear": {
"type": "http",
"url": "https://mcp.linear.app/mcp",
"oauth_resource": "https://mcp.linear.app/mcp"
},
"linear2": {
"type": "http",
"url": "https://mcp.linear2.app/mcp",
"oauth_resource": "https://mcp.linear2.app/mcp"
}
}
}
```
2a. **login in with api key** and observe plugin details page which
shows no apps (note we don't show "app not available due to api key log
in as there's no way to differentiate between no apps and app without
substitute mcp exists" without significantly more code changes, i've
separated this to a follow up if we want that behaviour.
<img width="1170" height="279" alt="Screenshot 2026-06-15 at 23 45 40"
src="https://github.com/user-attachments/assets/d36cb160-fbec-461e-9643-9c761dbae7bb"
/>
<img width="975" height="640" alt="Screenshot 2026-06-15 at 18 40 30"
src="https://github.com/user-attachments/assets/90ec0bc8-7506-4b90-bbd3-070720de799e"
/>
2b. **log in with chat** and observe intended conflict resolution logic
<img width="1165" height="224" alt="Screenshot 2026-06-15 at 17 17 30"
src="https://github.com/user-attachments/assets/80adfbf2-7dac-4f08-8b76-8eeeab6c95e7"
/>
<img width="968" height="567" alt="Screenshot 2026-06-15 at 18 38 59"
src="https://github.com/user-attachments/assets/9ea92c5e-535b-4aa4-8ad0-ee513b57bc3c"
/>
…8367) ## Why Clients running an app-server on one OS and an exec-server on another OS need to be able to pass sandbox config to app-server that refers to resources on the executor's foreign OS. ## What `AbsolutePathBuf` can't represent these paths and we don't want users to be exposed to `PathUri` yet, so this moves the public app-server API to be expressed in terms of `ApiPathString`. Stacked on openai#28165. - change app-server v2 filesystem permission paths, including legacy read/write roots, to `ApiPathString` - localize API paths through `PathUri` when converting into the current native core permission types - make path-bearing permission conversions fallible and surface localization failures instead of silently treating malformed grants as ordinary denials - propagate conversion failures through app-server and TUI approval handling - regenerate the app-server JSON and TypeScript schemas - leave migration TODOs on native-path conversions so they can be removed once core permission paths use `PathUri`
…28421) ## Why Shell snapshots are currently session-scoped even though shell and cwd are properties of a selected turn environment. That makes snapshot refresh depend on separate session-cwd plumbing, prevents retained environments from retaining their snapshot work, and can make snapshot construction use a different shell than command execution. This follows openai#27955 by making the retained thread-environment service own environment snapshot lifecycles. Session configuration remains the requested selection state, while `ThreadEnvironments` remains the source of successfully resolved environments. ## What changed - Configure the shell-snapshot builder before initial environment resolution. - Start each local environment snapshot task when its `TurnEnvironment` is built and retain that shared task while environment ID and cwd still match. - Inherit retained environment snapshots into spawned child threads. - Carry the selected `TurnEnvironment` through shell runtimes so snapshot construction and command execution use the same environment-specific shell and cwd. - Load project instructions and warm plugins/skills after initial environment resolution. - Continue decoding invalid UTF-8 instruction files lossily without emitting a startup warning. - Keep requested selections in `SessionConfiguration`; failed or duplicate resolutions only affect the resolved environment snapshot. ## Validation - `cargo check -p codex-core --tests` - `just test -p codex-home instructions` (6 passed) - Focused environment, instruction, shell-snapshot, and user-shell tests (84 passed) - Focused shell-snapshot, user-shell, and unified-exec tests (126 passed; two event-timing tests passed on retry)
## Why Models sometimes need to pause briefly while waiting for external work, but using a shell command for that delay ties the wait to a process and does not naturally resume when new turn input arrives. ## What changed - add a built-in `sleep` tool behind the under-development `sleep_tool` feature - accept a bounded `duration_ms` argument, matching the millisecond convention used by unified exec - end the sleep early when either steered user input or mailbox input arrives - include elapsed wall-clock time in completed and interrupted outputs - emit a dedicated core `SleepItem` through `item/started` and `item/completed` - expose the sleep item as app-server v2 `ThreadItem::Sleep` and retain it in reconstructed thread history - regenerate the configuration schema for the new feature flag - regenerate app-server JSON and TypeScript schema fixtures ## Test plan - `just test -p codex-core sleep_tool_follows_feature_gate` - `just test -p codex-core any_new_input_interrupts_sleep` - `just test -p codex-app-server-protocol` - `just test -p codex-app-server sleep_emits_started_and_completed_items`
The workspace denies `clippy::expect_used` in production. Although `clippy.toml` allows `expect` in tests, Bazel Clippy compiles integration-test helper code in a way that does not receive that exemption, which encouraged verbose `unwrap_or_else(... panic!(...))` and equivalent `match`/`let else` forms. This allows `clippy::expect_used` once at each integration-test crate root (including aggregated suites and test-support libraries), then replaces manual panic-based Result and Option unwraps with `expect`/`expect_err`. Standalone `tests/*.rs` files remain their own crate roots. Intentional assertion and unexpected-variant panics remain unchanged, and the production `expect_used = "deny"` lint remains in place. The cleanup is mechanical and net-negative in line count.
## Why User shell commands still read the legacy turn cwd and session shell even though execution context is now owned by selected turn environments. App-server also defines `thread/shellCommand` as a local-host escape hatch, so it must use an available local environment even when a remote environment is primary. ## What changed - Add `ResolvedTurnEnvironments::local()` to find the selected local environment. - Resolve the user shell command cwd and shell from that local `TurnEnvironment`. - Emit the standard `shell is unavailable in this session` error when no selected local environment or resolved local shell is available. - Add an integration test covering `/shell` without a local environment. ## Test plan - `just test -p codex-core user_shell_command_without_local_environment_emits_error`
Termux rust-v0.141.0-alpha.3
…nt/wallentx_termux-target_from_release_0.141.0_28fe11ec54f0
wallentx
deleted the
checkpoint/wallentx_termux-target_from_release_0.141.0_28fe11ec54f0
branch
June 16, 2026 21:14
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Termux release checkpoint
release/0.141.028fe11ec54f030c1a05dc09c43c1e43c45c79abfwallentx/termux-targetThis PR carries release-train conflict fixes and follow-up changes back into the reusable Termux patch branch.
Release-only workflow files and metadata under
.githubwere restored to the destination branch versions before opening this PR.