7390 Commits

This Branch

This Branch

All Branches

• Add executor-owned plugin resolution (#27692)

  ## Why
  
  CCA can select a capability root that lives in an executor environment,
  but
  Codex only had a host-filesystem plugin loader. Before selected executor
  plugins can contribute MCP servers, we need a small package boundary
  that can
  answer:
  
  > Does this selected root contain a plugin, and if so, what does its
  manifest
  > declare?
  
  The answer must come from the selected environment's filesystem. A
  failed
  executor lookup must never fall back to the orchestrator filesystem.
  
  ## What this changes
  
  This PR introduces:
  
  ```rust
  PluginProvider::resolve(root)
      -> Result<Option<ResolvedPlugin>, Error>
  ```
  
  `ExecutorPluginProvider` resolves one `SelectedCapabilityRoot` through
  its
  exact `environment_id`. It checks the recognized manifest locations,
  reads the
  manifest through that environment's `ExecutorFileSystem`, and returns an
  inert
  `ResolvedPlugin` containing:
  
  - the opaque selected-root ID;
  - the environment-bound plugin root;
  - the authority-bound manifest resource;
  - parsed metadata and authority-bound component locators.
  
  Descriptor construction rejects manifest or component paths outside the
  selected package root, so consumers cannot accidentally lose the package
  boundary when they receive a resolved plugin.
  
  If the root has no plugin manifest, resolution returns `None`, allowing
  the
  caller to treat it as a standalone capability such as a skill.
  
  ```text
  selected root: repo -> env-1:/workspace/repo
                           |
                           | env-1 filesystem only
                           v
               .codex-plugin/plugin.json
                           |
                           v
          ResolvedPlugin { authority, root, manifest }
  ```
  
  The existing host loader and the new executor provider now share the
  same
  manifest parser. Existing `codex-core-plugins::manifest` type paths
  remain
  available through re-exports, so host behavior and callers are
  unchanged.
  
  ## Scope
  
  This is intentionally a non-user-visible package-resolution PR. It does
  not:
  
  - parse or register plugin MCP server configurations;
  - activate skills, connectors, hooks, or MCP servers;
  - change app-server wiring;
  - introduce host fallback, caching, or lifecycle behavior.
  
  #27670 has merged, and this PR is now based directly on `main`. Together
  with
  the resolved MCP catalog from #27634, it establishes the inputs needed
  for the
  executor stdio MCP vertical without changing the existing MCP runtime.
  
  ## Follow-up
  
  The next PR will consume `ResolvedPlugin`, read its declared/default MCP
  config
  through the same executor filesystem, bind supported stdio servers to
  that
  environment, and feed those registrations into the resolved MCP catalog.
  An
  app-server E2E will prove that selecting an executor plugin exposes and
  invokes
  its tool on the owning executor.
  
  Resume/fork semantics, dynamic environment replacement, and non-stdio
  placement remain separate lifecycle decisions.
  
  ## Validation
  
  - `just fmt`
  - `cargo check --tests -p codex-plugin -p codex-core-plugins`
  - `just bazel-lock-check`
  - `git diff --check`
  
  Test targets were compiled but not executed locally; CI will run the
  test and
  Clippy suites.

  jif · 2026-06-12 13:37:33 +02:00
  267eacfca2
• [code-mode] Reject remote image URLs from output helpers (#27732)

  ## Summary
  
  - reject HTTP(S) image URLs from the shared code-mode output-image
  normalization path
  - return a concise model-visible tool error so the model can recover on
  its next turn
  - apply the targeted rejection to both `image()` and `generatedImage()`
  - leave other non-empty image URL values to existing downstream handling
  
  The returned error is:
  
  > Tool call failed: remote image URLs are not supported in tool outputs.
  Pass a base64 data URI instead
  
  ## Why
  
  Responses Lite cannot lower a remote image URL emitted from a structured
  tool output. Rejecting HTTP(S) values in the Codex harness preserves the
  tool-call metadata and gives the model a recoverable next turn instead
  of invalidating the sample.
  
  ## Test coverage
  
  The regression is covered primarily by a `test_codex()` agent
  integration test that simulates the Responses API exchange and asserts
  the failed model-visible exec output. A supplemental runtime test covers
  both `http://` and `https://` inputs across both image output helpers.
  
  ## Test plan
  
  - `cd codex-rs && just test -p codex-code-mode`
  - `cd codex-rs && just test -p codex-code-mode-protocol`
  - `cd codex-rs && just test -p codex-core
  code_mode_image_helper_rejects_remote_url`
  - `cd codex-rs && just fmt`
  - `git diff --check origin/main...HEAD`
  
  Related context: https://github.com/openai/openai/pull/1022346

  rka-oai · 2026-06-12 02:49:17 -07:00
  c09df9e353
• Make MCP server contributions thread-scoped (#27670)

  ## Why
  
  `selectedCapabilityRoots` belongs to one thread, but MCP contributors
  previously received only the global Codex config. That left no clean way
  for a selected executor capability to contribute MCP servers to its own
  thread.
  
  ## What this PR does
  
  - Gives MCP contributors a small context containing the config and, for
  a running thread, its frozen host-seeded inputs.
  - Uses the same thread inputs during startup, status queries, refreshes,
  and skill dependency checks.
  - Keeps threadless MCP operations and the existing hosted Apps behavior
  unchanged.
  - Adds coverage showing that two threads resolve independent
  registrations and that later lifecycle mutations do not change the
  frozen MCP inputs.
  
  This PR does not discover plugin manifests, add MCP servers, or launch
  anything new. It only establishes the thread-scoped registration
  boundary.
  
  ## Follow-ups
  
  - Resolve selected executor plugin roots through their owning
  environment filesystem.
  - Convert their stdio MCP declarations into environment-bound
  registrations and add an executor MCP end-to-end test.
  
  ## Verification
  
  - `just fmt`
  - `cargo check --tests -p codex-protocol -p codex-extension-api -p
  codex-mcp-extension -p codex-core -p codex-app-server`
  
  Tests and Clippy were not run.

  jif · 2026-06-12 11:20:34 +02:00
  693082f3c4
• [codex] Load AGENTS.md from all bound environments (#27696)

  ## Why
  
  We already have the machinery to support multiple environments on a
  single thread, but we only show the model the contents of `AGENTS.md`
  files in the primary environment.
  
  We should show the model all of the relevant project instructions when
  we know there's more than one environment.
  
  ## Known Gaps
  
  As discussed in the RFC, this implementation:
  
  1. doesn't handle environments being added/removed to/from the thread
  after its creation
  2. it doesn't enforce an aggregate context budget across environments,
  and instead applies the configured project maximum independently to each
  environment
  
  ## Implementation
  
  - Discover project instructions in environment order with an independent
  byte budget per environment and preserve source provenance/order.
  - Keep the legacy fragment byte-for-byte when exactly one environment
  contributes project instructions; use environment-labeled sections when
  two or more environments contribute.
  - Freeze the complete rendered fragment in `LoadedAgentsMd`, insert it
  directly into requests, and recognize both layouts in contextual and
  memory filtering.
  - Add exact rendering, independent-budget, source-order,
  creation-snapshot, and consumer coverage without changing app-server
  schemas.

  Adam Perry @ OpenAI · 2026-06-12 00:10:06 -07:00
  bf667c7003
• Keep request_user_input direct-model only (#27316)

  ## Why
  
  `request_user_input` has direct blocking semantics when invoked by the
  model. When it is exposed as a nested code-mode tool, the call has to
  flow through code-mode waiting and continuation behavior instead, which
  is not the behavior we want for this user-input request surface.
  
  ## What changed
  
  - Mark `request_user_input` with `ToolExposure::DirectModelOnly` when
  registering the core utility tool.
  - Keep `request_user_input` direct-model visible, including in
  code-mode-only planning.
  - Add focused `spec_plan_tests` coverage that verifies
  `request_user_input` remains visible and registered as
  direct-model-only, while it is omitted from the nested code-mode tool
  description.
  
  No active goal suppression or runtime unavailability behavior is
  included in this PR.
  
  ## Validation
  
  - No new build/test run for this housekeeping pass, per maintainer
  request.
  - Earlier targeted run, confirmed from session context: `just test -p
  codex-core request_user_input` passed.

  Shijie Rao · 2026-06-11 23:23:44 -07:00
  7a19b14229
• Translate non-English issues (#27778)

  Issues written in languages other than English, such as #26979, require
  manual translation before the development team can triage them.
  
  This adds an `Issue Translator` workflow that uses Codex when an issue
  is opened. For non-English reports, it replaces the title with an
  English translation, preserves the original body, and posts the
  translated body as an idempotent issue comment.
  
  The translation scripts were run manually against non-English issue
  content and produced the expected English title and comment output.

  Eric Traut · 2026-06-11 23:20:36 -07:00
  a94deb5fa7
• code-mode standalone: extract protocol and add host crate (#27724)

  This is phase 1 of a 4 phase stack:
  1. **Add protocol and host crates for new IPC code mode implementation**
  2. Create the new standalone binary
  3. Create a new IPC `CodeModeSessionProvider` to use new binary
  4. Remove v8 from core and only use IPC provider
  
  
  ## Add protocol and host crates for new IPC code mode implementation
  Establish a clean process boundary without changing the existing
  in-process behavior.
  
  - Add the codex-code-mode-protocol crate for shared session, runtime,
  response, and tool-definition types.
  - Move protocol-facing code out of the V8-backed implementation.
  - Add a buildable codex-code-mode-host crate as the foundation for the
  standalone process.
  - Keep the existing in-process runtime as the active implementation.

  Channing Conger · 2026-06-11 22:37:26 -07:00
  aa46f2debf
• Add request_user_input auto-resolution window contract (#27256)

  ## Why
  
  `request_user_input` is moving beyond its original plan-mode-only
  workflow, and future default/goal-mode usage needs a way for the model
  to ask helpful but non-blocking questions without forcing the turn to
  wait forever. This PR adds an explicit `autoResolutionMs` contract so a
  later client/runtime change can auto-resolve unanswered prompts after a
  bounded window while leaving truly blocking questions unchanged.
  
  This is contract plumbing only; it does not implement the client-side
  timer or auto-selection behavior, and the model-facing description
  treats the field as reserved unless the current runtime explicitly
  supports auto-resolution.
  
  ## What Changed
  
  - Added optional `autoResolutionMs` to the model-facing
  `request_user_input` args and core `RequestUserInputEvent`.
  - Added model-facing schema text for `autoResolutionMs` while marking it
  reserved for runtimes that explicitly support auto-resolution.
  - Bounds `autoResolutionMs` to `60_000..=240_000` ms during argument
  normalization by clamping out-of-range model-provided values.
  - Propagated the field through app-server v2
  `ToolRequestUserInputParams`, app-server request forwarding, generated
  TypeScript, and JSON schema fixtures.
  - Updated app-server, core, protocol, and TUI call sites/tests so
  omitted values preserve existing `None`/`null` behavior and coverage
  verifies a `Some(60_000)` round trip.
  
  ## Verification
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core request_user_input`
  - `just test -p codex-app-server request_user_input_round_trip`
  - `just test -p codex-tui request_user_input`
  - `just test -p codex-protocol`

  Shijie Rao · 2026-06-11 22:30:41 -07:00
  216ce03031
• [1 of 3] Support long raw TUI goal objectives (#27508)

  ## Stack
  
  1. **[1 of 3] Support long raw TUI goal objectives** - this PR
  2. [2 of 3] Support long pasted text in TUI goals - #27509
  3. [3 of 3] Support images in TUI goals - #27510
  
  ## Why
  
  `thread/goal/set` limits persisted objective text to 4000 characters.
  The TUI used to reject raw `/goal` objectives above that limit, even
  though the client can make them usable by writing the long text to a
  file and storing a short objective that points at that file.
  
  This also needs to work for remote app-server sessions: filesystem API
  calls must create files on the app-server host, and the stored path must
  be meaningful to the agent on that host.
  
  ## What Changed
  
  - Adds an app-server-host path helper so TUI code can build paths that
  are resolved on the app-server host rather than the TUI host.
  - Adds TUI app-server session helpers for `fs/createDirectory`,
  `fs/writeFile`, `fs/readFile`, and `fs/remove` that work for embedded
  and remote app-server sessions without changing the app-server protocol.
  - Materializes oversized raw `/goal` objectives into
  `$CODEX_HOME/attachments/<uuid>/goal-objective.md` through the
  app-server filesystem APIs, then stores a short, readable objective that
  directs the agent to that file.
  - Reads managed objective files back for `/goal edit`. Other goal UI
  renders the readable stored objective normally, without
  managed-file-specific presentation logic.
  - Recognizes managed references only when they name the expected
  generated file under the app server's reported `$CODEX_HOME`, and cleans
  up newly materialized files when goal replacement or setting does not
  complete.
  
  ## Verification
  
  - Added/updated TUI tests for raw oversized `/goal` submission, large
  inline-paste expansion, queued oversized goals, app-facing
  materialization before `thread/goal/set`, managed-path validation,
  editing, and cleanup.
  - Added/updated app-server-client remote coverage for initialized remote
  Codex home handling.
  
  ## Manual Testing
  
  - Ran the real TUI against a Unix-socket app server with different local
  and server `$CODEX_HOME` directories. Oversized goals wrote only under
  the server home, and persisted references used the server-canonical path
  rather than the TUI path.
  - Exercised 3,999-, 4,000-, and 4,001-character raw objectives. The
  first two stayed inline without new files; the 4,001-character objective
  became a managed objective file.
  - Submitted a larger 8,275-character objective, verified its full
  contents on the app-server host, and observed the goal continuation open
  the referenced server-side file.
  - Opened `/goal edit` for a managed objective and verified the full text
  was restored through remote `fs/readFile`.
  - Submitted an oversized replacement while a goal was active, verified
  no file was written before confirmation, then canceled and confirmed
  that the existing goal and attachment count were unchanged.

  Eric Traut · 2026-06-11 22:26:31 -07:00
  78bab04116
• feat(app-server): persist remote-control desired state (#27445)

  ## Why
  
  Remote-control runtime enablement and persisted enrollment preference
  were represented by separate flags. That made startup rehydration, RPC
  persistence, and new-enrollment seeding race with one another, and it
  did not cleanly distinguish runtime-only CLI or daemon starts from
  durable app-server RPC changes.
  
  ## What Changed
  
  - Replace the parallel enablement, seed, and rehydration flags with one
  transport-owned `RemoteControlDesiredState`.
  - Add nullable enrollment-scoped persistence and preserve existing
  preferences during enrollment upserts.
  - Rehydrate plain startup only after auth and client scope resolve,
  without overwriting a concurrent RPC transition.
  - Make ordinary `remoteControl/enable` and `remoteControl/disable`
  durable while retaining `ephemeral: true` for runtime-only callers.
  - Have the daemon explicitly request ephemeral enablement and regenerate
  the app-server schemas.
  
  ## Verification
  
  - Covered migration and `NULL`/`0`/`1` persistence round trips.
  - Covered plain-start rehydration and runtime-only versus durable
  enrollment seeding.
  - Covered durable enable, durable disable, and ephemeral enable through
  app-server RPC.
  - Covered the daemon's exact `{ "ephemeral": true }` request payload.
  
  Related issue: N/A (internal remote-control persistence architecture
  change).

  Anton Panasenko · 2026-06-11 21:28:52 -07:00
  d61dfeb23a
• [codex] resolve environment shell metadata eagerly (#27709)

  ## Why
  
  Turn construction passed resolved environments through several layers
  while leaving the environment shell unresolved. As a result,
  model-visible environment context could fall back to the session shell
  instead of reporting the selected remote environment's shell.
  
  Resolve environment metadata at the turn-context boundary so each turn
  carries the shell that belongs to its selected environment. Keep request
  validation in app-server, where invalid selections can be returned as
  straightforward JSON-RPC errors without coupling core turn construction
  to that policy.
  
  ## What changed
  
  - resolve environment selections eagerly in
  `new_turn_context_from_configuration`
  - store the full resolved `Shell` on each `TurnEnvironment`
  - simplify the now-redundant resolved-environment constructor plumbing
  - keep duplicate and unknown-environment validation as a small
  app-server preflight
  - add a remote-environment integration test that runs a full
  `test_codex` turn and verifies the model-visible environment message
  reports `bash`
  
  ## Testing
  
  - `cargo check -p codex-core --test all -p codex-app-server`
  - `remote_test_env_exposes_bash_shell_to_model` on the Linux
  remote-executor harness

  pakrym-oai · 2026-06-11 20:35:28 -07:00
  be338ee9a2
• [codex] parallelize release code generation (#27702)

  The release profile still uses one codegen unit, which serializes LLVM
  code generation within each crate. That setting was selected alongside
  fat LTO for optimization quality and binary size, but releases now use
  ThinLTO and code generation dominates the critical-path build.
  
  Use four codegen units. On an Apple M4 Max with 16 cores and 128 GiB
  RAM, using rustc 1.96.0, four and eight units took 507.486 and 505.325
  seconds respectively. Four therefore keeps the build-time gain while
  limiting the stripped `codex` increase to 14.7%, compared with 21.5% at
  eight units. The gzip-compressed binary grows 7.8% at four units.
  
  The one-unit build from an empty target directory took 981.150 seconds.
  That comparison also populated dependency and native build caches, so it
  is directional rather than controlled. It agrees with the earlier clean
  matrix where eight units reduced 671 seconds to 303 seconds:
  https://gist.github.com/anp/4b88393a0acd35783d9f42156f3243d5
  
  At the local 48% reduction, the current release's 55m22s critical-path
  macOS Cargo step would save about 26 minutes from the 71m28s workflow:
  https://github.com/openai/codex/actions/runs/27367405663
  
  The prompt-image medians ranged from 3.9% faster to 0.9% slower. CLI
  startup shifted by 1-2 ms while user and system CPU time were unchanged.
  
  This is a draft because the release-latency improvement may not justify
  the binary-size increase.

  Tamir Duberstein · 2026-06-11 19:44:36 -07:00
  e23d4df4ff
• ci(v8): gate Windows source builds on relevant changes (#27715)

  Avoid rebuilding sandboxed Windows MSVC V8 artifacts for unrelated
  changes to `codex-rs/Cargo.toml`.
  
  The V8 canary now compares the resolved V8 version between the base and
  head commits and only runs the Windows source-build matrix when:
  
  - the resolved V8 crate version changes;
  - Windows artifact-production scripts or workflows change; or
  - the workflow is manually dispatched.
  
  The existing Bazel V8 matrix is unchanged.
  
  ## Why
  
  The Windows MSVC source builds take roughly two to three hours and
  currently run whenever any entry in the broad `v8-canary` path filter
  changes.

  Channing Conger · 2026-06-11 18:44:42 -07:00
  16c7c79540
• fix: Recover from sqlite directory being a file (#27719)

  Missed this file in the last PR -- this ensures that if you're in the
  really-weird edge case of your sqlite directory being a file, that it
  will fix it and recover properly.

  David de Regt · 2026-06-11 18:23:16 -07:00
  69b0f52b2a
• [codex] Remove async_trait from first-party code (#27475)

  ## Why
  
  First-party async traits should expose their `Send` contracts explicitly
  without requiring `async_trait`. This completes the migration pattern
  established in #27303 and #27304.
  
  ## What changed
  
  - Replaced the remaining first-party `async_trait` traits with native
  return-position `impl Future + Send` where statically dispatched and
  explicit boxed `Send` futures where object safety is required.
  - Kept implementations behavior-preserving, outlining existing async
  bodies into inherent methods where that keeps the diff reviewable.
  - Removed all direct first-party `async-trait` dependencies and the
  workspace dependency declaration.
  - Added a cargo-deny policy that permits `async-trait` only through the
  remaining transitive wrapper crates.
  - Updated `rand` from 0.8.5 to 0.8.6 to resolve RUSTSEC-2026-0097 and
  keep the full cargo-deny check passing.
  
  ## Validation
  
  - `just test -p codex-exec-server`: 216 passed, 2 skipped.
  - `just test -p codex-model-provider`: 39 passed.
  - `just test -p codex-core` and `just test`: changed tests passed;
  remaining failures are environment-sensitive suites unrelated to this
  migration.
  - `cargo deny check`
  - `just fix`
  - `just fmt`
  - `cargo shear`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 18:16:39 -07:00
  5a56caf18c
• Fix image extension PathUri conversion (#27711)

  ## Why
  
  `main` stopped compiling when #27498 passed an `AbsolutePathBuf` to the
  `ExecutorFileSystem` API migrated to `PathUri` by #27653.
  
  ## What
  
  Convert referenced image paths to `PathUri` before filesystem reads,
  declare the internal path-URI dependency, and refresh `Cargo.lock`.

  Adam Perry @ OpenAI · 2026-06-12 00:15:19 +00:00
  1829ed1122
• tui: clear stale hook row after turn completion (#27619)

  Fixes #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`)

  Mitsuhiro Kotake · 2026-06-12 09:15:04 +09:00
  44403dd3dd
• Add spans to turn lifecycle gaps (#27623)

  ## 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

  mchen-oai · 2026-06-11 16:55:01 -07:00
  92d9036910
• Route image extension reads through turn environments v2 (#27498)

  ## 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.

  Won Park · 2026-06-11 16:32:52 -07:00
  19ce6394af
• [codex] Move persistence policy application into ThreadStore (#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.

  Tom · 2026-06-11 16:24:12 -07:00
  b2cc01fc7c
• Warn when hooks.json has unsupported top-level fields (#26426)

  Addresses #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.

  Abhinav · 2026-06-11 23:08:07 +00:00
  eddc5c75ed
• Remove fs/join and fs/parent from exec-server protocol (#27700)

  ## 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)

  Adam Perry @ OpenAI · 2026-06-11 15:48:53 -07:00
  e069153f2a
• feat: prefer managed Bedrock auth in model provider (#27689)

  ## 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.

  Celia Chen · 2026-06-11 15:33:38 -07:00
  b7a5d81f84
• [codex] Avoid duplicate hooks.json discovery with profiles (#26418)

  ## 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 #25645 and addresses the single-cwd duplication in #25437.
  
  ## Validation
  
  - `cargo nextest run -p codex-hooks`
  - `just fix -p codex-hooks`
  - `just fmt`
  - `just argument-comment-lint -p codex-hooks`

  Abhinav · 2026-06-11 15:25:55 -07:00
  0d8dee9427
• Include thread id in token budget context (#27663)

  ## 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`

  pakrym-oai · 2026-06-11 15:10:29 -07:00
  7516eb5c70
• [codex] migrate exec-server filesystem protocol to PathUri (#27653)

  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.

  Adam Perry @ OpenAI · 2026-06-11 15:09:12 -07:00
  d23bb22f25
• [codex-rs] enforce PAT workspace restrictions (#27450)

  ## 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

  cooper-oai · 2026-06-11 14:17:37 -07:00
  b5f1bb75d4
• core: Consolidate Responses API Codex metadata (#27122)

  ## 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`

  Owen Lin · 2026-06-11 13:42:09 -07:00
  14df0e8833
• Resolve MCP server registrations through a catalog (#27634)

  ## 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`

  jif · 2026-06-11 21:54:52 +02:00
  4a5a676499
• [codex] Load user instructions through an injected provider (#27101)

  ## 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 #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`

  Adam Perry @ OpenAI · 2026-06-11 19:28:47 +00:00
  236b50125d
• [codex] migrate ExecutorFileSystem paths to PathUri (#27424)

  ## 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.

  Adam Perry @ OpenAI · 2026-06-11 18:44:18 +00:00
  b2a4e3be27
• [codex] remove EnvironmentPathRef (#27433)

  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 #27454.

  Adam Perry @ OpenAI · 2026-06-11 18:26:12 +00:00
  4a05d3b282
• [codex] Provide ARM64 MinGW powl compatibility support (#27323)

  ## 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 #27322.

  Adam Perry @ OpenAI · 2026-06-11 11:21:47 -07:00
  0b08bbb9d9
• feat: disable orchestrator skills for now (#27646)

  Temp disable orchestrator-only skills while waiting for the endpoint to
  be fixed

  jif · 2026-06-11 20:20:26 +02:00
  267232f3af
• [codex] revert concurrent npm publishing (#27639)

  In https://github.com/openai/codex/actions/runs/27354608310, the
  concurrency introduced by
  
  https://github.com/openai/codex/commit/5e50e7e639c9284ceac24a5498b73a5602fb6615
  caused the npm publish job to fail.
  
  The six platform tarballs contain different versions of the same
  `@openai/codex` package. Every publish updates the same packument, so
  only two concurrent updates succeeded while four failed with HTTP 409.
  
  Serializing that group would leave only the responses API proxy running
  in parallel. Saving one publish does not justify the nested `xargs`
  machinery needed to express those groups.
  
  Restore the serial publish loop and document why the platform variants
  must not publish concurrently. Platform packages remain ahead of the
  root CLI wrapper, and the SDK remains after its exact root dependency.

  Tamir Duberstein · 2026-06-11 18:04:24 +00:00
  b42bff21bb
• [codex] Surface runtime warnings in codex exec (#27415)

  ## Why
  
  `codex exec` drops thread-scoped warning notifications. Warnings
  discovered while a thread starts, including unreadable or invalid UTF-8
  project `AGENTS.md` files, therefore become silent.
  
  ## What changed
  
  - Process global and primary-thread warning notifications while
  continuing to ignore warnings from unrelated threads.
  - Render runtime warnings in human output and expose them through the
  existing non-fatal error item in JSONL output.
  - Add focused routing, rendering, and malformed project-instruction
  coverage.

  Adam Perry @ OpenAI · 2026-06-11 14:01:16 -04:00
  7fbbc9f033
• [codex] add cross-platform filesystem adapter coverage (#27454)

  ## Why
  
  The exec-server's existing filesystem tests only run on `#[cfg(unix)]`.
  We should be running the applicable ones on Windows, and also include
  the basic filesystem operations that will be modified by migrating to
  `PathUri`.
  
  ## What
  
  Split platform-neutral local/remote tests into a shared Unix/Windows
  suite while keeping the existing `AbsolutePathBuf` API, and add Windows
  junction canonicalization coverage.

  Adam Perry @ OpenAI · 2026-06-11 17:53:18 +00:00
  cc97839068
• [codex] Propagate plugin app categories (#27420)

  ## What
  - Parse optional `.app.json` `category` overrides for plugin apps.
  - Add nullable `category` to `AppSummary` and `AppTemplateSummary` in
  the app-server protocol.
  - Fall back from `branding.category` to the first non-empty
  `app_metadata.categories` value when building app/template summaries.
  - Regenerate schema/type fixtures and update plugin read/install tests.
  
  ## Why
  The plugin details UI needs a normalized per-app category. Some apps
  only provide their default category in metadata, while others need a
  local `.app.json` override.

  charlesgong-openai · 2026-06-11 10:34:41 -07:00
  eb76336f60
• lint: allow self-documenting builder arguments (#27507)

  Builder-style setters often repeat the setting name in both the method
  and its sole argument. Calls such as `.enabled(false)` are already
  self-documenting, so requiring `/*enabled*/` adds noise without
  clarifying the call.
  
  ## What changed
  
  - Exempt a method's sole non-self argument when its resolved parameter
  name matches the method name.
  - Continue validating any explicit argument comment against the resolved
  parameter name.
  - Continue requiring comments when method and parameter names differ or
  when a method has multiple non-self arguments.
  - Document the exception in `AGENTS.md` and the lint's own behavior
  documentation.
  
  ## Examples
  
  Before this change we'd need redundant comments like this:
  
  ```rust
  builder.enabled(/*false*/ false);
  builder.retry_count(/*retry_count*/ 3);
  builder.base_url(/*base_url*/ None);
  ```
  
  Now can be written like this:
  
  ```rust
  builder.enabled(false);
  builder.retry_count(3);
  builder.base_url(None);
  ```
  
  Still disallowed:
  
  ```rust
  client.set_flag(true); // Method name does not match parameter `enabled`.
  options.enabled(false, /*retry_count*/ 3); // More than one non-self argument.
  options.enabled(/*value*/ false); // Explicit comment does not match `enabled`.
  ```
  
  ## Validation
  
  Added UI coverage for boolean, numeric, and `None` builder arguments,
  multi-argument methods, and explicit comment mismatches. Ran `rustup run
  nightly-2025-09-18 cargo test` in `tools/argument-comment-lint`.

  Adam Perry @ OpenAI · 2026-06-11 10:24:42 -07:00
  52db447c77
• Print TUI session info on fatal exits (#27417)

  ## Summary
  
  TUI exits printed the resume/session summary only after checking the
  exit reason. On fatal exits, both CLI wrappers wrote the error and
  called `process::exit(1)` immediately, so an active session that ended
  on a fatal error could skip the session information entirely.
  
  This change prints the normal exit summary before returning the fatal
  nonzero exit code. If a fatal exit has a known thread id but no
  resumable rollout hint, it prints `Session ID: <id>` instead of staying
  silent. It also flushes stdout before `process::exit(1)` so the summary
  line is not lost during process teardown.
  
  ## Implementation
  
  - Apply the fatal-exit ordering fix in both `codex` and standalone
  `codex-tui`.
  - Keep normal user-requested exit behavior unchanged.
  - Preserve the existing resume hint when a rollout is resumable, and use
  the raw thread id only as a fatal-exit fallback.

  Eric Traut · 2026-06-11 09:56:09 -07:00
  9d88e299a7
• Emit plugin ID on MCP tool call analytics events (#27483)

  MCP tool-call items already carry the runtime-resolved plugin owner, but
  the analytics reducer dropped that field. Forwarding the existing value
  provides direct attribution without downstream server-name inference.
  
  ## Summary
  
  - emit `plugin_id` on `codex_mcp_tool_call_event` payloads
  - preserve `null` for MCP calls without a plugin owner
  - verify the serialized field through the MCP item lifecycle test
  
  ## Test
  
  - `cd codex-rs && just test -p codex-analytics`
  - `cd codex-rs && just fix -p codex-analytics`
  - `cd codex-rs && just fmt`

  Chris Dong · 2026-06-11 09:55:53 -07:00
  df9dd22248
• Remove TUI legacy Windows sandbox dependency (#27490)

  ## Why
  
  This is part of an ongoing attempt to eliminate the TUI's direct
  dependency on core features. When we moved the TUI to the app server, we
  left a `legacy_core` shim that re-exported some remaining core symbols
  for the TUI. The intent was to eventually remove all of these.
  
  In this PR, we remove the symbols related to the Windows sandbox.
  
  The change should be behavior-neutral and low risk because it's just
  refactoring and removal of code that is now effectively dead.
  
  When working on this PR, I noticed a big existing problem that affects
  mixed-platform remoting. For example, if you run the TUI on a Linux box
  and remote into a Windows box, the TUI logic doesn't properly handle
  Windows sandbox setup properly. Fixing this is beyond the scope of this
  PR, but I've left a TODO comment in place so we don't forget.
  
  ## What changed
  
  - Move the remaining TUI-specific sandbox level, setup, telemetry, and
  read-root helpers into `codex-tui`, calling `codex-windows-sandbox`
  directly.
  - Remove the Windows sandbox namespace and read-root grant re-exports
  from the client-side `legacy_core` facade.
  - Remove the dormant pre-elevation prompt fallback guarded by the
  permanently enabled `ELEVATED_SANDBOX_NUX_ENABLED` switch. The reachable
  elevated and non-elevated setup flows remain unchanged.

  Eric Traut · 2026-06-11 09:23:08 -07:00
  1e5b87b4d7
• [codex] download only release artifacts (#27529)

  In https://github.com/openai/codex/actions/runs/27308011621, the
  release job downloaded 10.0 GiB of workflow artifacts in 87 seconds,
  then discarded 42 artifacts accounting for 3.3 GiB.
  
  Select target and supplemental release artifact patterns at download
  time. This also excludes duplicate Cargo timing files without a cleanup
  pass and should reduce total release time by about 30 seconds.

  Tamir Duberstein · 2026-06-11 10:34:41 -04:00
  f42780109c
• [codex] publish DotSlash alongside npm (#27528)

  In https://github.com/openai/codex/actions/runs/27308011621,
  preparing and publishing the three DotSlash configurations took 72
  seconds after creating the GitHub release. npm publication could not
  start until those independent steps finished.
  
  Move DotSlash publication to a sibling job that starts after the GitHub
  release. npm and DotSlash can then proceed concurrently, reducing total
  release time by about one minute.

  Tamir Duberstein · 2026-06-11 10:23:46 -04:00
  9163c0a335
• [codex] publish npm packages concurrently (#27527)

  In https://github.com/openai/codex/actions/runs/27308011621,
  publishing the npm tarballs serially took 147 seconds. Six platform
  packages and the responses API proxy are independent.
  
  Publish those packages concurrently, then publish the root CLI wrapper
  and SDK in dependency order. Individual platform publishes took 19 to
  23 seconds, so this should reduce total release time by nearly two
  minutes.

  Tamir Duberstein · 2026-06-11 07:19:27 -07:00
  5e50e7e639
• skills: decouple the skills extension from core (#27413)

  ## Why
  
  `ext/skills` currently depends on `codex-core` for two host concerns:
  reading the concrete `Config` type and borrowing core-owned
  model-context fragment types. That coupling prevents the extension from
  being assembled independently above core and leaves context that belongs
  to the skills feature owned by core.
  
  This stacked PR introduces the host boundary needed for the broader
  extension migration while intentionally preserving existing skills
  behavior. It is stacked on #27404.
  
  ## What changed
  
  - Adds a small public `SkillsExtensionConfig` view and makes skills
  installation generic over the host config type.
  - Requires the host to map its config into that view; app-server
  supplies the current `Config` values.
  - Moves the available-skills and selected-skill context fragment
  implementations into `ext/skills`, preserving their roles, markers, and
  rendered bytes.
  - Removes the direct `codex-core` dependency from
  `codex-skills-extension`.
  - Keeps local discovery, invocation, side effects, and the
  `codex-core-skills` compatibility types unchanged for later staged PRs.
  
  ## Behavior
  
  This adds no capability and is intended to have no user-visible or
  model-visible behavior change. The install API and ownership boundary
  change internally; emitted skills context remains byte-for-byte
  compatible.
  
  ## Validation
  
  - Updates the skills extension integration coverage to use a host-owned
  test config.
  - Asserts the complete rendered catalog and selected-skill fragments,
  including their roles and markers.
  - `just bazel-lock-check`
  - Rust tests and Clippy were not run locally per request; CI will run
  them.

  jif · 2026-06-11 14:03:53 +02:00
  7c2394808e
• skills: render catalog locators by authority (#27591)

  ## Why
  
  Hosted skills introduced by #27388 use opaque `skill://` resource
  identifiers, but the skills catalog rendered every locator as a `file`
  and told the model that every skill body lived on disk. That can send
  the model toward filesystem tools for a resource that must instead be
  read through its owning authority.
  
  The catalog should describe how each source is accessed without changing
  the underlying discovery or invocation behavior.
  
  ## What changed
  
  - Render host skills as `file`, executor-owned skills as `environment
  resource`, orchestrator-owned skills as `orchestrator resource`, and
  custom-provider skills as `custom resource`.
  - Update the shared no-alias guidance to describe source locators rather
  than assuming every skill is stored on the host filesystem.
  - Direct orchestrator resources through `skills.list` and `skills.read`,
  and explicitly tell the model not to treat `skill://` identifiers as
  filesystem paths.
  - Preserve the existing filesystem and alias behavior for local skills.
  
  ## Scope
  
  This PR changes only model-visible catalog rendering and guidance. It
  does not change skill discovery, selection, prompt injection, provider
  routing, catalog caching or refresh behavior, resource validation, or
  the `skills.*` tool contract.
  
  ## Verification
  
  - Extended skills-extension coverage for host-file and executor-resource
  labels.
  - Extended the no-executor app-server flow to assert
  orchestrator-resource wording and non-filesystem guidance.

  jif · 2026-06-11 13:51:04 +02:00
  4322e01d2b
• test: cover referenced backend skill reads without an executor (#27404)

  ## Why
  
  PR #27388 lets models read child resources referenced by backend plugin
  skills without an executor. The integration fixture should prove that
  real flow: the injected `SKILL.md` advertises a child `skill://`
  resource, and `skills.read` resolves that exact resource through the
  backend provider.
  
  This is stacked on #27388.
  
  ## What changed
  
  - Adds a child-resource link to the backend skill fixture and asserts
  that it reaches model context.
  - Tightens the end-to-end skills test around `skills.list` followed by
  `skills.read` for the referenced resource.
  - Splits the existing app-server `mcpResource/read` coverage into a
  focused test so the generic RPC path remains covered independently.
  
  ## Validation
  
  - Adds app-server integration coverage for both the referenced backend
  skill resource and the generic MCP resource read path.

  jif · 2026-06-11 12:55:58 +02:00
  dd46ef1aac
• nit: cap error (#27585)

  Just cap an error that could end up in the model context

  jif · 2026-06-11 12:52:46 +02:00
  e6757bba91
• multi-agent: move concurrency guidance into v2 usage hints (#27569)

  ## Why
  
  Native Codex currently teaches multi-agent concurrency through the
  `spawn_agent` tool description, while bridge-driven evals frame the same
  limit as a shared pool of active agent slots. That mismatch makes the
  model-facing story harder to reason about, especially because the
  tool-level wording does not make it explicit that the limit covers the
  whole agent team, including the current agent.
  
  This change gives native Codex the same mental model: tell the root
  agent and subagents how many active slots exist, and remove the separate
  `spawn_agent` limit wording.
  
  ## What changed
  
  - Extend the built-in `multi_agent_v2` root and subagent usage hints
  with shared-slot guidance derived from the resolved
  `max_concurrent_threads_per_session` value.
  - Keep the complete default hints in `MultiAgentV2Config` so initial
  context and forked histories consume the same canonical strings.
  - Drop the redundant `spawn_agent` description text and remove the
  now-unused limit plumbing from the tool spec path.
  
  ## Testing
  
  - `just test -p codex-core usage_hint`
  - `just test -p codex-core
  multi_agent_v2_default_session_thread_cap_counts_root`
  - `just test -p codex-core
  multi_agent_v2_default_usage_hints_use_configured_thread_cap`
  - `just test -p codex-core
  spawn_agent_tool_v2_requires_task_name_and_lists_visible_models`
  - `just test -p codex-core
  multi_agent_feature_selects_one_agent_tool_family`

  jif · 2026-06-11 12:41:44 +02:00
  0870352241