checkpoint: into wallentx/termux-target from release/0.140.0 @ b7ba1972c3ff - #215
Merged
wallentx merged 24 commits intoJun 12, 2026
Conversation
Temp disable orchestrator-only skills while waiting for the endpoint to be fixed
## Why Windows ARM64 uses 64-bit `long double`, but the LLVM MinGW Bazel configuration omits the upstream `powl` compatibility source and does not link the `mingwex` archive that owns it. Cross-linking the release binary therefore fails with an unresolved `powl` symbol. ## What changed Patch the LLVM module to compile `math/arm-common/powl.c` into the ARM64 MinGW extension sources and add `-lmingwex` to the Windows toolchain defaults. ## Validation - `just bazel-lock-check` Stack: 3 of 6. Depends on openai#27322.
We're switching to using a static encoding of the host path in `PathUri`. We may need a type like this again but we can add it when it's more compelling. Stacked on openai#27454.
## Why We're moving exec-server to use PathUri for its internal path representations. ## What Move `ExecutorFileSystem` APIs to use `PathUri` instead of `AbsolutePathBuf`. Future changes will convert higher-level parts of exec-server.
…7101) ## Why We want to remove implicit use of `$CODEX_HOME` from `codex-core` and make embedders responsible for supplying user-level instructions. This also ensures user instructions load when no primary environment is selected. ## What changed Stacked on openai#27415, which makes `codex exec` surface thread-scoped runtime warnings. - Added `UserInstructionsProvider` to `codex-extension-api`, with absolute source attribution and recoverable loading warnings. - Added `codex-home` with the filesystem-backed provider for `AGENTS.override.md` and `AGENTS.md`, preserving precedence, fallback, trimming, lossy UTF-8 handling, and the existing uncapped global instruction size. - Removed global instruction loading from `Config` and require `ThreadManager` callers to inject a provider. - Load provider instructions once for each fresh root runtime, including runtimes without a primary environment. Running sessions retain their snapshot, while child agents inherit the parent snapshot without invoking the provider. - Keep provider instructions separate while loading project `AGENTS.md`, then assemble the model-visible instructions with the existing ordering, source attribution, warning, and turn-context behavior. - Wired the Codex home provider through the CLI, app server, MCP server, core facade, and thread-manager sample. ## Validation - `just test -p codex-home -p codex-extension-api` - `just test -p codex-core agents_md` - `just test -p codex-core guardian` - `just test -p codex-app-server thread_start_without_selected_environment_includes_only_global_instruction_source` - `just test -p codex-exec warning` - `just bazel-lock-check`
## Why MCP servers currently come from user config, local plugins, compatibility Apps synthesis, and host extensions. Those sources were composed by mutating a shared map, leaving registration identity, precedence, removal, and provenance implicit in assembly order. Before adding executor-owned MCPs, Codex needs one durable resolution boundary above `McpConnectionManager`. This PR introduces that boundary while preserving current server configuration, policy, and runtime behavior. Executor-scoped registrations and explicit policy layers remain follow-ups. ## What changed - Add typed `McpServerRegistration` inputs and an immutable `ResolvedMcpCatalog` in `codex-mcp`. - Retain each registration's complete `McpServerConfig`, including its environment binding, while recording its source and provenance. - Preserve the existing structural precedence between plugin, config, compatibility, and ordered extension sources. - Resolve equal-precedence actions by contribution order; provenance IDs are used only for diagnostics and cannot affect the winner. - Preserve extension removals and the existing name-scoped `enabled = false` veto. - Report same-tier conflicts with every contender and the final catalog outcome, including whether the winning action registers or removes the server. - Require MCP contributors to provide a stable diagnostic identity. - Derive materialized server maps and plugin ownership from the resolved catalog. `McpConnectionManager`, transport startup, tool calls, and resource routing continue to consume the same effective `McpServerConfig` values. ## Scope This PR does not add new MCP capabilities or change user-visible behavior. It does not add executor plugin discovery, thread-scoped registrations, dynamic refresh generations, or new user/managed policy semantics. ## Verification - Added focused catalog coverage for source precedence, complete configuration preservation, disabled vetoes, plugin ownership, contribution-order tie breaking, removal outcomes, and conflict diagnostics. - Extended hosted Apps coverage for ordered extension removal and Apps-disabled hosts with and without the hosted extension installed. - `cargo check -p codex-mcp --tests -p codex-extension-api -p codex-core`
## What Introduce a `CodexResponsesMetadata` struct that defines all the core metadata we send to Responses API. Example fields are `thread_id`, `turn_id`, `window_id`, etc. Going forward, `client_metadata["x-codex-turn-metadata"]` will be the canonical way Codex sends metadata to Responses API across both HTTP and websocket transports. For now, we continue to emit the existing top-level HTTP headers and top-level `client_metadata` fields from the same `CodexResponsesMetadata` struct for compatibility reasons. Also, app-server clients who specify additional `responsesapi_client_metadata` via `turn/start` and `turn/steer` will have those fields merged into `client_metadata["x-codex-turn-metadata"]`, but cannot override the reserved fields that core uses (i.e. the fields in `CodexResponsesMetadata`). ## Why Responses API request instrumentation is the source of truth for downstream Codex analytics that join requests by Codex IDs such as session, thread, turn, and context window. Before this change, those values were assembled through several request-specific paths: HTTP request bodies, websocket handshake headers, websocket `response.create` payloads, compaction requests, and the rich `x-codex-turn-metadata` envelope all had their own wiring. That made metadata propagation easy to drift across API-key/direct Responses API requests, ChatGPT-auth/proxied requests, websocket requests, and compaction requests. It also made additions like `window_id` error-prone because a field could be added to one transport projection but missed in another. ## What changed - Added `CodexResponsesMetadata` as the core-owned snapshot for Codex metadata sent to ResponsesAPI. - Render `client_metadata["x-codex-turn-metadata"]`, flat `client_metadata` projections, and direct compatibility headers from that same snapshot. - Include the known Codex-owned fields in the turn metadata blob, including installation/session/thread/turn/window IDs, request kind, lineage, sandbox/workspace metadata, timing, and compaction details. - Treat app-server `responsesapi_client_metadata` as enrichment for the Codex turn metadata blob while preventing those extras from overriding Codex-owned fields. - Use the same metadata path for normal turns, websocket prewarm, local compaction, remote v1 compaction, and remote v2 compaction. - Keep websocket connection-only preconnect metadata separate so handshakes carry compatibility identity headers without inventing a fake turn metadata blob. ## Verification - `cargo check -p codex-core` - `just fix -p codex-core`
## Summary - validate a hydrated personal access token's workspace against `forced_chatgpt_workspace_id` before persisting `codex login --with-access-token` - apply the same PAT-only check when restricted auth managers load environment, ephemeral, or persisted credentials - enforce PAT workspace restrictions in the existing central login-restriction path - leave Agent Identity and cloud bootstrap behavior unchanged ## Scope This is intentionally the small PAT-only change. It does not attempt the broader auth-manager/bootstrap unification; that needs separate design work. ## Validation - `CARGO_INCREMENTAL=0 CARGO_TARGET_DIR=/tmp/codex-pat-target just test -p codex-login -p codex-cli` (410 passed) - `CARGO_INCREMENTAL=0 CARGO_TARGET_DIR=/tmp/codex-pat-target just fix -p codex-login -p codex-cli` - `just fmt` - `git diff --check` Context: https://openai.slack.com/archives/D0AUPLV03RQ/p1781138331548269
) Exec-server filesystem calls should preserve cross-platform `file:` URIs across the remote boundary instead of converting them through paths native to the client host. This changes the exec-server filesystem protocol DTOs to use `PathUri`, carries those values directly through remote and sandbox-helper transports, and keeps legacy native absolute-path request strings readable for compatibility. It also updates protocol documentation and coverage for URI serialization and non-native URI forwarding.
## Why The token budget full-context fragment identifies the current context window, but not the thread that owns that window. Including the thread id makes the initial context-window metadata self-contained, and `get_context_remaining` also needs to be usable from Code Mode without forcing callers to parse the model-facing fragment string. ## What changed - Include the session thread id in the initial `<token_budget>` context fragment. - Expose `get_context_remaining` as a Code Mode nested tool while keeping `new_context` direct-model-only. - Keep direct model-facing `get_context_remaining` output as the existing `<token_budget>` text fragment. - Return only `tokens_left` from the Code Mode structured result for `get_context_remaining`. - Update token-budget integration tests and add Code Mode coverage for the structured result. ## Verification - `just test -p codex-core token_budget` - `just test -p codex-core code_mode_get_context_remaining_returns_structured_result` - `just test -p core_test_support redacted_text_mode_normalizes_uuids`
) ## Summary V2 profiles add both `config.toml` and `<profile>.config.toml` to the config stack. Because both user layers resolve hook discovery to the same Codex home, Codex loaded the same `hooks.json` twice. This duplicated hook rows and caused each matching command to run twice. Deduplicate JSON hook discovery by absolute config folder within each effective config stack. TOML hooks remain layer-specific, and multi-cwd `hooks/list` results remain independently resolved per cwd. ## Reproduction 1. Add `config.toml` and `work.config.toml` under `$CODEX_HOME`. 2. Add one command hook to `$CODEX_HOME/hooks.json`. 3. Run Codex with `--profile work`. 4. Trigger the hook. Before this change, one declaration creates two handlers. Afterward, it creates one. Fixes openai#25645 and addresses the single-cwd duplication in openai#25437. ## Validation - `cargo nextest run -p codex-hooks` - `just fix -p codex-hooks` - `just fmt` - `just argument-comment-lint -p codex-hooks`
## Why The Amazon Bedrock model provider currently discards the shared `AuthManager`, so a Codex-managed Bedrock API key cannot reach request-time provider auth. Bedrock instead falls through to AWS environment or SDK credentials, and the request endpoint can be resolved from a different region than the managed credential. Managed Bedrock login should control both the bearer credential and Mantle region. Unrelated OpenAI or ChatGPT credentials must remain isolated from Bedrock. ## What changed - Pass the shared `AuthManager` into `AmazonBedrockModelProvider`. - Select `CodexAuth::BedrockApiKey` before the existing `AWS_BEARER_TOKEN_BEDROCK` and AWS SDK/SigV4 paths. - Use the managed Bedrock auth region when resolving the Mantle endpoint. - Filter other `CodexAuth` variants so OpenAI and ChatGPT auth are not exposed to Bedrock request auth or unauthorized recovery. - Add focused coverage for provider construction, managed-auth precedence, bearer headers, endpoint selection, and OpenAI-auth isolation.
## Summary Path composition is already handled by `PathUri`, leaving `fs/join` and `fs/parent` as redundant exec-server protocol surface. Because app-server and exec-server are deployed atomically, these obsolete methods can be removed without a compatibility shim. This removes the protocol constants and payloads, public client APIs, server registrations and handlers, and endpoint-only tests. Existing in-process `PathUri` join/parent coverage remains. ## Validation - `just test -p codex-exec-server` (215 passed, 2 skipped)
Addresses openai#25875. ## Summary `hooks.json` accepted unknown top-level fields. A file with `SessionStart` at the root parsed as an empty hook configuration without warning. ## Repro ```json { "SessionStart": [...] } ``` Previously: zero hooks, zero warnings. Now: ```text unknown field `SessionStart`, expected `hooks` ``` The supported shape remains: ```json { "hooks": { "SessionStart": [...] } } ``` ## Fix Reject unknown top-level fields and surface the parse warning in human and JSONL `codex exec` output.
…27318) Move the application of the persistence policy into the thread store, so thread stores can get raw append items rather than canonical append items. This will enable store-specific projections over the raw input items.
## Why Image generation used `std::fs::read` for referenced image paths, which did not support environment-backed filesystems or their sandbox context. ## What changed - Expose optional turn environments to extension tool calls. - Include each environment’s ID, working directory, filesystem, and sandbox context. - Read referenced images through the selected environment filesystem. - Keep sandbox usage at the extension call site so extensions can choose the appropriate access mode. - Consolidate image request construction into one async function. - Add coverage for successful environment reads and read failures. ## Validation - `cargo check -p codex-image-generation-extension --tests` - `just fmt` - `just bazel-lock-update` - `just bazel-lock-check` `just test -p codex-image-generation-extension` could not complete because the build exhausted available disk space.
## Why Codex app-server latency traces do not granularly cover turn task startup and inter-request handoffs. These spans help attribute time across task execution, startup prewarm, in-flight tool completion, and rollout persistence. ## What changed - Add `session_task.run` spans around task execution and `session_task.flush_rollout` around flushing pending conversation transcript writes to durable storage - Add `regular_task.prepare_run_turn` around regular-turn startup (Send the `TurnStarted` event, reset turn-specific reasoning state, and resolve any startup prewarm) - Add `startup_prewarm.resolve` around waiting for background session prewarming to finish, fail, time out, or be cancelled - Add a function-level trace span around draining in-flight tool calls (Wait for tool calls to complete, record tool result in conversation history, and other bookkeeping) ## Verification Trigger Codex rollout and observe new spans are included
Fixes openai#27210. ## Why When the app server reports a visible `HookStarted` event for a `PostToolUse` hook but the turn reaches `TurnCompleted` before a matching hook completion event arrives, the TUI can leave the transient `Running PostToolUse hook` row visible after the agent is done. Interrupted and failed turn cleanup already drops transient live hook rows; the normal completion path did not. ## What Changed - Added `ChatWidget::clear_active_hook_cell()` for dropping transient live hook status without writing it to history. - Call that cleanup from normal task completion, while reusing it for the existing start/finalize cleanup paths. - Added `completed_turn_clears_visible_running_hook` snapshot coverage for the reported `PostToolUse` case. ## Tests - `just test -p codex-tui completed_turn_clears_visible_running_hook` - `just test -p codex-tui` (fails on current `main` in unrelated guardian tests: `update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default` and `update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history`)
## Why `main` stopped compiling when openai#27498 passed an `AbsolutePathBuf` to the `ExecutorFileSystem` API migrated to `PathUri` by openai#27653. ## What Convert referenced image paths to `PathUri` before filesystem reads, declare the internal path-URI dependency, and refresh `Cargo.lock`.
Termux rust-v0.140.0-alpha.13
…nt/wallentx_termux-target_from_release_0.140.0_b7ba1972c3ff
wallentx
deleted the
checkpoint/wallentx_termux-target_from_release_0.140.0_b7ba1972c3ff
branch
June 12, 2026 02:24
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
12 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.140.0b7ba1972c3ffced7efb3bd4311be88bf94ee6b5cwallentx/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.