29 Commits

• extension-api: add TurnItemEmitter to tool calls (#24813)

  ## Why
  Extension-contributed tools need to emit visible turn items through
  Codex's normal event and persistence pipeline.
  
  ## What
  - Add `TurnItemEmitter` to extension `ToolCall`s and route the core
  implementation through `Session::emit_turn_item_*`.
  - Hold weak session and turn references so retained tool calls cannot
  keep host state alive.
  - Provide a no-op emitter for extension test callers.
  
  ## Test Plan
  - `just test -p codex-core -E
  'test(passes_turn_fields_and_scoped_turn_item_emitter_to_extension_call)'`
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  sayan-oai · 2026-05-28 09:13:43 -07:00
  2066874415
• Add turn error lifecycle contributor (#24916)

  Summary
  - Add TurnErrorInput and TurnLifecycleContributor::on_turn_error to the
  extension API.
  - Emit the turn-error lifecycle from core turn error paths, including
  usage limit failures.
  - Add direct lifecycle coverage for the emitted error facts and stores.
  
  Tests
  - just fmt
  - git diff --check
  - Not run: full tests or clippy (per instructions)

  jif-oai · 2026-05-28 16:13:54 +02:00
  e7d156eb08
• Add thread start contributor facts (#24915)

  Summary: add session source and persistent-state availability to
  ThreadStartInput; populate them from session init; update existing goal
  test harness constructors. Tests: just fmt; git diff --check. No full
  tests or clippy run per request.

  jif-oai · 2026-05-28 16:10:55 +02:00
  ec803fe6c7
• feat: add thread idle lifecycle hook (#24744)

  ## Why
  
  Extensions can currently observe thread start, resume, and stop, but
  they do not have a lifecycle point for the host to say that immediately
  pending thread work has drained. That makes idle follow-up behavior
  harder to express as extension-owned logic instead of host-specific
  plumbing.
  
  This adds an explicit idle lifecycle hook so an extension can react when
  a thread becomes idle while the host keeps ownership of whether any
  submitted follow-up input starts a turn, is queued, or is ignored.
  
  ## What changed
  
  - Added `ThreadIdleInput` with access to the session-scoped and
  thread-scoped extension stores.
  - Added a default `on_thread_idle` method to
  `ThreadLifecycleContributor`.
  - Re-exported `ThreadIdleInput` from the extension API surface.
  
  ## Testing
  
  Not run; this only extends the extension API trait surface with a
  default hook and exported input type.

  jif-oai · 2026-05-27 15:17:23 +02:00
  d2ebb8d8ca
• fix: dont compact standalone websearch schema (#24660)

  add new `parse_tool_input_schema_without_compaction` to bypass the
  existing compaction/trimming of client-provided tool schemas that are
  over 4k bytes.
  
  we want this for standalone web search to keep field guidance/metadata
  on certain fields; this keeps us closer to parity with existing hosted
  tool schema (which didnt go through this 4k byte filter).

  sayan-oai · 2026-05-27 01:05:19 +00:00
  9fe55d68e6
• Expose conversation history to extension tools (#23963)

  ## Why
  
  Extension tools that need conversation context should be able to read it
  from the live tool invocation instead of reaching into thread
  persistence themselves.
  
  ## What changed
  
  - Add a `ConversationHistory` snapshot to extension `ToolCall`s and
  populate it from the current raw in-memory response history.
  - Expose all history items at this boundary so each extension can filter
  and bound the subset it needs before consuming or forwarding it.
  - Cover the adapter and registry dispatch paths and update existing
  extension tests that construct `ToolCall` literals.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-extension-api`
  - `cargo test -p codex-goal-extension`
  - `cargo test -p codex-memories-extension`
  - `cargo test -p codex-core passes_turn_fields_to_extension_call`
  - `cargo test -p codex-core
  extension_tool_executors_are_model_visible_and_dispatchable`

  sayan-oai · 2026-05-22 01:11:47 +00:00
  7e802b22f1
• [codex] Steer budget-limited goal extension turns (#23718)

  ## What
  - Add a small extension capability for injecting model-visible response
  items into the active turn
  - Have the goal extension inject hidden goal-context steering when
  tool-finish accounting reaches `BudgetLimited`
  - Cover the extension backend path with an assertion on the injected
  steering item
  
  ## Why
  PR #23696 persists and emits the budget-limited goal update from
  tool-finish accounting, but it leaves the model unaware of that
  transition. The existing core runtime steers the model to wrap up in
  this case; the extension path should do the same through an explicit
  host capability.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-goal-extension`
  - `cargo test -p codex-extension-api`

  jif-oai · 2026-05-21 12:54:00 +02:00
  791b69dd53
• feat: expose turn-start metadata to extensions (#23688)

  ## Why
  
  The goal extension needs more context when a turn starts than
  `turn_store` alone provides.
  
  In particular, goal accounting needs the stable turn id, the effective
  collaboration mode, and the cumulative token-usage baseline captured at
  turn start so it can:
  
  - suppress goal accounting for plan-mode turns
  - compute exact per-turn deltas from cumulative `total_token_usage`
  snapshots instead of relying on the most recent usage event alone
  - keep the extension-owned accounting path aligned with the host turn
  lifecycle
  
  ## What
  
  - extend `codex_extension_api::TurnStartInput` to expose `turn_id`,
  `collaboration_mode`, and `token_usage_at_turn_start`
  - pass the full `TurnContext` plus the captured token-usage baseline
  through the turn-start lifecycle emission path
  - initialize goal turn accounting from the turn-start baseline and
  collaboration mode
  - switch goal token accounting to compute deltas from cumulative
  `total_token_usage` snapshots
  - add coverage for the new turn-start lifecycle fields and for
  goal-accounting baseline behavior
  
  ## Testing
  
  - added `turn_start_lifecycle_exposes_turn_metadata_and_token_baseline`
  in `codex-rs/core/src/session/tests.rs`
  - added `ext/goal/tests/accounting.rs` coverage for baseline-aware goal
  accounting and plan-mode suppression

  jif-oai · 2026-05-20 15:54:29 +02:00
  59507b8491
• feat: async turn item process (#23692)

  Mechanical change

  jif-oai · 2026-05-20 15:30:01 +02:00
  1392a2a770
• feat: async approval contrib (#23690)
  jif-oai · 2026-05-20 15:13:54 +02:00
  f64fce61b3
• Add tool lifecycle extension contributor (#23309)

  ## Why
  
  Extensions that need to track runtime progress currently have no typed
  host signal for tool execution. The goal extension in particular needs
  to observe tool attempts without inspecting tool payloads, owning tool
  implementations, or staying coupled to core-only runtime plumbing.
  
  This adds a narrow lifecycle contributor API for host-owned tool
  execution: extensions can observe when an accepted tool call starts and
  how it finishes, while policy hooks and tool handlers continue to own
  payload rewriting, blocking, and execution.
  
  Relevant code:
  
  -
  [`ToolLifecycleContributor`](https://github.com/openai/codex/blob/3ad2850ffc7d8a1da19c65a92425637a59098f1b/codex-rs/ext/extension-api/src/contributors.rs#L119)
  defines the extension-facing observer contract.
  -
  [`tool_lifecycle.rs`](https://github.com/openai/codex/blob/3ad2850ffc7d8a1da19c65a92425637a59098f1b/codex-rs/ext/extension-api/src/contributors/tool_lifecycle.rs)
  defines the typed start/finish inputs, source, and outcome enums.
  - [`notify_tool_start` /
  `notify_tool_finish`](https://github.com/openai/codex/blob/3ad2850ffc7d8a1da19c65a92425637a59098f1b/codex-rs/core/src/tools/lifecycle.rs)
  bridges core tool dispatch into the extension registry.
  
  ## What Changed
  
  - Added `ToolLifecycleContributor` to `codex-extension-api`, including:
    - `ToolStartInput`
    - `ToolFinishInput`
    - `ToolCallSource`
    - `ToolCallOutcome`
  - Added registration and lookup support on `ExtensionRegistryBuilder` /
  `ExtensionRegistry`.
  - Wired core tool dispatch to notify lifecycle contributors for:
    - accepted tool starts
    - completed tool calls, including the tool output success marker
    - pre-tool-use blocks
    - failures before or after the handler runs
    - cancellation/abort in the parallel tool path
  - Registered the goal extension as a lifecycle contributor and added the
  outcome filter it will use for goal progress accounting.
  
  ## Test Coverage
  
  - Added `dispatch_notifies_tool_lifecycle_contributors` to cover
  lifecycle notification ordering and outcomes for successful and
  handler-failed tool calls.

  jif-oai · 2026-05-18 21:55:57 +02:00
  c69cde3547
• chore: make token usage async (#23305)

  Make the `TokenUsageContributor` async. This will be required for future
  extension and it's basically free

  jif-oai · 2026-05-18 15:59:06 +02:00
  b631d92170
• feat: add extension event sink capability (#23293)

  ## Why
  
  Extensions can already expose typed contributions and receive host
  capabilities such as `AgentSpawner`, but they do not have a typed way to
  send protocol events back through the host. Extensions that need to
  surface progress or status should not have to own persistence, ordering,
  transport fanout, or logging decisions themselves.
  
  ## What
  
  - Add `ExtensionEventSink`, a host-provided fire-and-forget sink for
  `codex_protocol::protocol::Event`.
  - Add `NoopExtensionEventSink` so hosts that do not expose extension
  event emission keep the existing empty-registry behavior.
  - Store the sink on `ExtensionRegistryBuilder` / `ExtensionRegistry`,
  with `with_event_sink(...)` and `event_sink()` accessors, and re-export
  the new capability from `codex-extension-api`.
  
  ## Testing
  
  - Not run locally; PR metadata/body update only.

  jif-oai · 2026-05-18 14:08:56 +02:00
  6a8173588c
• Make extension lifecycle hooks async (#23291)

  ## Why
  
  Extension lifecycle hooks sit on the host/extension boundary, but the
  current trait surface only allows synchronous callbacks. That forces
  extensions that need to seed, rehydrate, observe, or flush
  extension-owned state during thread and turn transitions to either block
  inside the callback or move async work into separate host plumbing.
  
  This PR makes those lifecycle callbacks awaitable so extension
  implementations can perform async work directly at the lifecycle point
  where the host already has the relevant session, thread, or turn stores
  available.
  
  ## What changed
  
  - Makes `ThreadLifecycleContributor` and `TurnLifecycleContributor`
  async in `codex-extension-api`.
  - Awaits thread start/resume/stop and turn start/stop/abort lifecycle
  callbacks from `codex-core`.
  - Updates the guardian and memories extensions to implement the async
  lifecycle trait surface.
  - Updates the existing lifecycle tests to use async contributor
  implementations.
  - Adds `async-trait` to the crates that now expose or implement these
  async object-safe lifecycle traits.
  
  ## Testing
  
  - Existing `codex-core` lifecycle tests were updated to cover async
  implementations for thread stop and turn abort ordering.

  jif-oai · 2026-05-18 13:53:58 +02:00
  9531e932ef
• Simplify tool executor and registry plumbing (#22636)

  ## Why
  
  The tool runtime path still had a typed output associated type on
  `ToolExecutor`, plus a core-only `RegisteredTool` adapter and
  extension-only executor aliases. That made every new shared tool runtime
  carry extra adapter plumbing before it could participate in core
  dispatch, extension tools, hook payloads, telemetry, and model-visible
  spec generation.
  
  This PR moves output erasure to the shared executor boundary so core and
  extension tools can use the same execution contract directly.
  
  ## What Changed
  
  - Changed `codex_tools::ToolExecutor` to return `Box<dyn ToolOutput>`
  instead of an associated `Output` type.
  - Removed the extension-specific `ExtensionToolExecutor` /
  `ExtensionToolOutput` aliases and exposed `ToolExecutor<ToolCall>` plus
  `ToolOutput` through `codex-extension-api`.
  - Reworked core tool registration around `CoreToolRuntime` and
  `ToolRegistry::from_tools`, removing the extra `RegisteredTool` /
  `ToolRegistryBuilder` layer.
  - Consolidated model-visible spec planning and registry construction in
  `core/src/tools/spec_plan.rs`, including deferred tool search and
  code-mode-only filtering.
  - Added `ToolOutput` helpers for post-tool-use hook ids and inputs so
  MCP, unified exec, extension, and other boxed outputs preserve the same
  hook payload behavior.
  - Updated core handlers, memories tools, and the related
  registry/spec/router tests to use the simplified contract.
  
  ## Test Coverage
  
  - Updated coverage for tool spec planning, registry lookup, deferred
  tool search registration, extension tool routing, post-tool-use hook
  payloads, dispatch tracing, guardian output extraction, and memories
  extension tool execution.

  jif-oai · 2026-05-15 11:47:54 +02:00
  6f1a01fbdd
• feat: make ToolExecutor an async trait (#22560)

  ## Why
  
  `codex_tools::ToolExecutor` keeps a tool spec attached to its runtime
  handler, but extension tools still carried a parallel
  `ExtensionToolFuture` / `ExtensionToolExecutor` shape. That made
  extension-owned tools look different from host tools even though
  routing, registration, and execution need the same abstraction.
  
  This PR makes the shared executor contract directly async and lets
  extension tools implement it too, so host tools and extension tools can
  move through the same registration path.
  
  ## What changed
  
  - Changed `ToolExecutor::handle` to an `async fn` using `async-trait`,
  and updated built-in tool handlers to implement the async trait
  directly.
  - Replaced the bespoke `ExtensionToolFuture` contract with a marker
  `ExtensionToolExecutor` over `ToolExecutor<ToolCall, Output =
  JsonToolOutput>`, re-exporting `ToolExecutor` from
  `codex-extension-api`.
  - Updated the memories extension tools to implement the shared executor
  trait.
  - Split tool-router construction into collected executors plus hosted
  model specs, keeping hosted tools like web search and image generation
  separate from executable handlers.
  - Updated spec/router tests and extension-tool stubs for the new
  executor shape.
  
  ## Verification
  
  - Not run locally.

  jif-oai · 2026-05-14 11:23:57 +02:00
  6d65686313
• fix: main (#22503)

  Fix main due to conflicting merge

  jif-oai · 2026-05-13 17:28:37 +02:00
  441c2f818f
• feat: add config-change extension contributor (#22488)

  ## Why
  
  Extensions can observe thread and turn lifecycle events today, but there
  was no single host-owned hook for changes to the effective thread
  configuration. That makes features that need to react to model,
  permission, or tool-suggest updates either depend on individual mutation
  paths or risk going stale after runtime config refreshes.
  
  This adds a typed config-change contributor so extension-owned state can
  stay synchronized with the effective thread config while the host
  remains responsible for deciding when config changed.
  
  ## What Changed
  
  - Added `ConfigContributor<C>` to `codex_extension_api`, with
  before/after immutable snapshots of the effective config plus
  session/thread extension stores.
  - Added registry builder/accessor support through `config_contributor`
  and `config_contributors`.
  - Emits config-change callbacks after committed updates from session
  settings, per-turn setting updates, and `refresh_runtime_config`.
  - Builds effective config snapshots only when config contributors are
  registered, and suppresses no-op callbacks when the before/after
  snapshots are equal.
  - Added a core session regression test that verifies contributors
  observe both model changes and user-layer runtime config changes,
  including access to session and thread extension stores.
  
  ## Validation
  
  Added `config_change_contributor_observes_effective_config_changes` in
  `codex-rs/core/src/session/tests.rs` to cover the new contributor path.

  jif-oai · 2026-05-13 17:13:34 +02:00
  34bb85519f
• Make context contributors async (#22491)

  ## Summary
  - make ContextContributor return a boxed Send future
  - await context contributors during initial context assembly
  - update existing contributors and extension-api examples for the async
  contract
  
  ## Testing
  - cargo test -p codex-extension-api --examples
  - cargo test -p codex-git-attribution
  - cargo test -p codex-core
  build_initial_context_includes_git_attribution_from_extensions --
  --nocapture
  - cargo test -p codex-core
  build_initial_context_omits_git_attribution_when_feature_is_disabled --
  --nocapture
  - cargo test -p codex-core (fails in unrelated
  agent::control::tests::spawn_agent_fork_last_n_turns_keeps_only_recent_turns
  stack overflow)
  - just fix -p codex-extension-api
  - just fix -p codex-git-attribution
  - just fix -p codex-core
  - cargo clippy -p codex-extension-api --examples

  jif-oai · 2026-05-13 16:43:28 +02:00
  68e045a631
• feat: move extension scope ids into ExtensionData (#22490)

  ## Summary
  - add a scoped level_id to ExtensionData and expose it through
  level_id()
  - remove thread_id/turn_id parameters from extension contributor inputs
  where the scoped ExtensionData already carries that identity
  - move turn-scoped extension data onto TurnContext so token usage and
  lifecycle contributors can share the same turn store
  
  ## Testing
  - cargo check -p codex-extension-api -p codex-core --tests
  - cargo test -p codex-extension-api
  - cargo test -p codex-guardian
  - cargo test -p codex-core --lib
  record_token_usage_info_notifies_extension_contributors
  - cargo test -p codex-core --lib
  submission_loop_channel_close_emits_thread_stop_lifecycle
  - cargo test -p codex-core --lib
  submission_loop_channel_close_aborts_active_turn_before_thread_stop_lifecycle
  - just fix -p codex-extension-api
  - just fix -p codex-guardian
  - just fix -p codex-core
  - just fmt
  
  ## Note
  - Attempted cargo test -p codex-core; it aborted in
  agent::control::tests::spawn_agent_fork_last_n_turns_keeps_only_recent_turns
  with the existing stack overflow before the full suite completed.

  jif-oai · 2026-05-13 16:13:16 +02:00
  1dcc89f1d4
• feat: add token usage contributor hook (#22485)

  ## Why
  
  Extensions need a stable place to observe token accounting after Codex
  folds model-provider usage into the session's cached `TokenUsageInfo`.
  Without a contributor hook, extension-owned features that need last-turn
  or cumulative token usage have to duplicate session plumbing or infer
  state from client-facing `TokenCount` notifications.
  
  ## What changed
  
  - Added `TokenUsageContributor` to `codex-extension-api`, passing
  session/thread `ExtensionData`, `ThreadId`, turn id, and the current
  `TokenUsageInfo`.
  - Added registry builder/storage support for token-usage contributors.
  - Invoked registered contributors from
  `Session::record_token_usage_info` after the session token cache is
  updated and before the client `TokenCount` notification is emitted.
  
  ## Testing
  
  - Added `record_token_usage_info_notifies_extension_contributors`,
  covering cumulative token usage updates and access to both extension
  stores.

  jif-oai · 2026-05-13 14:32:23 +02:00
  083c1962f9
• feat: add turn lifecycle contributors (#22480)

  ## Why
  
  Extensions can already contribute prompt, tool, turn-item, and
  thread-lifecycle behavior, but there was no explicit host-owned hook for
  per-turn setup and cleanup. That makes extension-private turn state
  awkward: an extension either has to stash it outside the turn lifecycle
  or depend on core runtime objects.
  
  This adds a small turn lifecycle boundary. Extensions receive stable
  identifiers plus the existing session, thread, and turn `ExtensionData`
  stores, while core keeps owning task scheduling, cancellation, and turn
  teardown.
  
  ## What Changed
  
  - Added `TurnLifecycleContributor` with `on_turn_start`, `on_turn_stop`,
  and `on_turn_abort` callbacks in `codex-rs/ext/extension-api`.
  - Added typed `TurnStartInput`, `TurnStopInput`, and `TurnAbortInput`
  payloads that expose `thread_id`, `turn_id`, `session_store`,
  `thread_store`, and `turn_store`.
  - Registered and re-exported turn lifecycle contributors through
  `ExtensionRegistry` and `ExtensionRegistryBuilder`.
  - Wired `Session` to emit turn start, stop, and abort callbacks from the
  existing turn/task lifecycle paths.
  - Carried the turn-scoped `ExtensionData` through `RunningTask` and
  `RemovedTask` so stop/abort callbacks receive the same turn store
  created at turn start.
  
  ## Verification
  
  - Not run locally.

  jif-oai · 2026-05-13 13:47:27 +02:00
  27e67a8c2a
• feat: add thread lifecycle contributor hooks (#22476)

  ## Why
  
  Extensions that need thread-scoped state currently only get a start-time
  callback. That is enough for seeding stores, but it leaves the host
  without a shared extension seam for later thread rehydrate and flush
  work as thread ownership evolves. This PR turns that start-only seam
  into a host-owned thread lifecycle contributor contract so
  extension-private state can stay behind the extension API instead of
  leaking extra orchestration through core.
  
  ## What changed
  
  - Replaced `ThreadStartContributor` with `ThreadLifecycleContributor`
  and added typed lifecycle inputs for thread start, resume, and stop. The
  contract lives in
  [`contributors/thread_lifecycle.rs`](https://github.com/openai/codex/blob/d0e9211f70e58d6b07ef07e84f359d1b9aa25955/codex-rs/ext/extension-api/src/contributors/thread_lifecycle.rs#L1-L64).
  - Kept the existing start-time behavior intact by routing session
  construction through `on_thread_start`.
  - Invoked `on_thread_stop` during session shutdown before thread-scoped
  extension state is dropped, while isolating contributor failures behind
  warning logs.
  - Migrated `git-attribution` and `guardian` onto the lifecycle
  registration path.
  - Renamed the extension registry plumbing from start-specific
  contributors to lifecycle-specific contributors.
  
  ## Notes
  
  `on_thread_resume` is introduced at the API boundary here so extensions
  can target the final lifecycle shape; host resume dispatch can be wired
  where that runtime path is finalized.

  jif-oai · 2026-05-13 13:11:30 +02:00
  5ab7e6b4c6
• Refactor extension tools onto shared ToolExecutor (#22369)

  ## Why
  
  Extension tools were split across two public runtime contracts:
  `codex-tool-api` exposed `ToolBundle` plus its own call/spec/error
  types, while core native tools used `codex_tools::ToolExecutor`. That
  made contributed tool specs and execution behavior easy to drift apart
  and added another crate boundary for what should be one executable-tool
  seam.
  
  This PR makes `ToolExecutor` the single runtime contract and keeps
  extension-specific pinning in `codex-extension-api`.
  
  ## Remaining todo
  
  https://github.com/openai/codex/pull/22369/changes#diff-b935ea8245c3ce568a30cff660175fa6390b66b872ae409e1e2e965738250741R5
  Either generic `Invocation` or sub-extract the `ToolCall` and clean
  `ToolInvocation`
  
  ## What changed
  
  - Removed the `codex-tool-api` workspace crate and its dependencies from
  core and `codex-extension-api`.
  - Made `codex_tools::ToolExecutor` object-safe with `async_trait` so
  extension contributors can return a dyn executor.
  - Added the extension-facing aliases under
  `ext/extension-api/src/contributors/tools.rs`, including
  `ExtensionToolExecutor = dyn ToolExecutor<ToolCall, Output =
  ExtensionToolOutput>`.
  - Changed `ToolContributor::tools` to return extension executors
  directly instead of `ToolBundle`s.
  - Updated core’s extension tool handler/registry/router path to adapt
  those extension executors into the existing native `ToolInvocation`
  runtime path.
  - Added focused coverage for extension tools being registered,
  model-visible, dispatchable, and not replacing built-in tools.
  
  ## Verification
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-extension-api`

  jif-oai · 2026-05-13 12:12:06 +02:00
  9c5dfa7b1a
• extension-api: add approval review contributor flow (#22344)

  ## Why
  
  `codex-extension-api` needs an approval hook that lets an installed
  extension own a rendered approval-review prompt and produce the final
  `ReviewDecision`. The prior interceptor stub only exposed a yes/no claim
  and did not model the review result itself, which left the host with the
  missing half of the control flow.
  
  ## What changed
  
  - Replaces `ApprovalInterceptorContributor` with
  [`ApprovalReviewContributor`](https://github.com/openai/codex/blob/c49d17531e15057a373a9b17f410cafb6299d0c1/codex-rs/ext/extension-api/src/contributors.rs#L43-L55),
  which may claim a rendered prompt and return an async `ReviewDecision`.
  - Re-exports the new contributor and future types from `extension-api`.
  - Adds registry support through `approval_review_contributor(...)` plus
  [`ExtensionRegistry::approval_review(...)`](https://github.com/openai/codex/blob/c49d17531e15057a373a9b17f410cafb6299d0c1/codex-rs/ext/extension-api/src/registry.rs#L90-L101),
  which returns the first installed contributor that claims the prompt.

  jif-oai · 2026-05-13 10:39:12 +02:00
  155c04ad40
• feat: guardian as an extension (contributors part) (#22216)

  Part 1 of guardian as extension. This bind all the logic to spawn
  another agent from an extension and it adds `ThreadId` in the start
  thread collaborator

  jif-oai · 2026-05-12 14:41:45 +02:00
  d996f5366f
• feat: wire extension tool bundles into core (#22147)

  ## Why
  
  This is the next narrow step toward moving concrete tool families out of
  core. After #22138 introduced `codex-tool-api`, we still needed a real
  end-to-end seam that lets an extension own an executable tool definition
  once and have core install it without the temporary `extension-api`
  wrapper or a dependency on `codex-tools`.
  
  `codex-tool-api` is the small extension-facing execution contract, while
  `codex-tools` still has a different job: host-side shared tool metadata
  and planning logic that is not “run this contributed tool”, like spec
  shaping, namespaces, discovery, code-mode augmentation, and
  MCP/dynamic-to-Responses API conversion
  
  ## What changed
  
  - Moved the shared leaf tool-spec and JSON Schema types into
  `codex-tool-api`, so the executable contract now lives with
  [`ToolBundle`](https://github.com/openai/codex/blob/c538758095337d4fe0a52a172363ccede4066bda/codex-rs/tool-api/src/bundle.rs#L19-L70).
  - Replaced the temporary extension-side tool wrapper with direct
  `ToolBundle` use in `codex-extension-api`.
  - Taught core to collect contributed bundles, include them in spec
  planning, register them through
  [`ToolRegistryBuilder::register_tool_bundle`](https://github.com/openai/codex/blob/c538758095337d4fe0a52a172363ccede4066bda/codex-rs/core/src/tools/registry.rs#L653-L667),
  and dispatch them through the existing router/runtime path.
  - Added focused coverage for contributed tools becoming model-visible
  and dispatchable, plus spec-planning coverage for contributed function
  and freeform tools.
  
  ## Verification
  
  - Added `extension_tool_bundles_are_model_visible_and_dispatchable` in
  `core/src/tools/router_tests.rs`.
  - Added spec-plan coverage in `core/src/tools/spec_plan_tests.rs` for
  contributed extension bundles.
  
  ## Related
  
  - Follow-up to #22138

  jif-oai · 2026-05-11 16:42:29 +02:00
  672cc1f669
• feat: drop CodexExtension (#22140)

  Drop `CodexExtension` as not needed for now

  jif-oai · 2026-05-11 14:19:51 +02:00
  ebd3d53451
• extension: add initial typed extension API (#21736)

  ## Why
  
  `codex-core` still owns a growing amount of product-specific behavior.
  This PR starts the extraction path by introducing a small, typed
  first-party extension seam: features can install the contribution
  families they actually own, while the host keeps lifecycle and state
  ownership instead of pushing a broad service locator into the API.
  
  See the `examples/` for illustration
  
  ## Known limitations
  * Tool contract definition will be shared with core
  * Fragments must be extracted
  * Missing some contributors

  jif-oai · 2026-05-11 11:06:24 +02:00
  d2c3ebac1f