78 Commits

• Add saved image path hint to standalone image generation (#25947)

  ## Why
  
  Standalone image generation returns image bytes to the model, but the
  model also needs the host artifact path to reference the generated file
  in follow-up work.
  
  ## What changed
  
  - Append the default saved-image path hint alongside the generated image
  tool output.
  - Reuse the existing core image-generation hint text.
  - Pass the thread ID and Codex home directory needed to compute the
  artifact path.
  - Add app-server and extension coverage for the model-visible hint.
  
  ## Validation
  
  - `just fmt`
  - `just bazel-lock-check`
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`

  Won Park · 2026-06-04 09:39:20 -07:00
  12e8764a9c
• Bridge host-loaded skills into the skills extension (#26172)

  ## Why
  
  The skills extension needs to become the path that exposes local host
  skills without losing the behavior already owned by core skill loading.
  Host skill discovery is not just `$CODEX_HOME/skills`: it also includes
  config layers, bundled-skill settings, plugin roots, runtime extra
  roots, and the filesystem for the selected primary environment.
  
  Rather than making the extension reload host skills and risk drifting
  from that authoritative load, this PR bridges the already-loaded
  per-turn skills outcome into the extension. That lets the extension
  advertise host skills and inject explicit `$skill` prompts while
  preserving the same roots, disabled/hidden state, rendered paths, and
  environment-backed file reads that the legacy path uses.
  
  ## What Changed
  
  - Adds `HostLoadedSkills` in `core-skills` to wrap the turn's
  `SkillLoadOutcome` and read `SKILL.md` through the filesystem that
  loaded that skill.
  - Stores `HostLoadedSkills` in turn extension data for normal turns and
  review turns, so the skills extension can consume the loaded host
  catalog without reloading it.
  - Adds `HostSkillProvider` under `ext/skills/src/provider/host.rs`,
  mapping host-loaded skill metadata into the skills-extension
  catalog/read contract.
  - Registers the host provider by default from
  `codex_skills_extension::install()`.
  - Preserves host skill metadata such as dependencies, disabled state,
  hidden-from-prompt policy, and slash-normalized display paths.
  - Passes host-loaded skills through `SkillListQuery` and
  `SkillReadRequest` so explicit skill invocation reads only resources
  from the loaded host catalog.
  - Adds integration coverage for a real legacy
  `$CODEX_HOME/skills/.../SKILL.md` skill being listed and injected
  through the installed extension.
  
  ## Testing
  
  - Added `installed_extension_loads_host_skills_from_legacy_roots` in
  `ext/skills/tests/skills_extension.rs`.
  - `just test -p codex-skills-extension`

  jif · 2026-06-04 15:28:06 +02:00
  d46a98d31a
• Gate automatic idle turns in Plan mode (#26147)

  ## Why
  
  Goal idle continuation is extension-triggered model-visible work, so it
  should follow one core-owned rule for when automatic work may start. In
  particular, it should not jump ahead of queued user/client work, start
  while another task is active, or inject a continuation turn while the
  thread is in Plan mode.
  
  Keeping this policy in `try_start_turn_if_idle` avoids passing
  `collaboration_mode` or review-specific state through
  `ThreadLifecycleContributor::on_thread_idle`. Active `/review` is
  covered by the same active-task gate because Review turns are not
  steerable.
  
  ## What Changed
  
  - Teach `Session::try_start_turn_if_idle` to reject automatic idle turns
  in Plan mode, both before reserving an idle turn and after building the
  turn context.
  - Document `CodexThread::try_start_turn_if_idle` as the extension-facing
  gate for automatic idle work, including Plan-mode and active Review-task
  behavior.
  - Add focused coverage for Plan-mode rejection and active Review-task
  rejection without queuing synthetic input.
  
  ## Testing
  
  - `just test -p codex-core try_start_turn_if_idle`

  jif · 2026-06-04 14:44:45 +02:00
  d297616d3e
• Implement v1 skills extension prompt injection (#26167)

  ## Why
  
  The skills extension needs a real turn-time path before host, executor,
  or remote skills can be routed through it. The previous code was mostly
  a placeholder catalog/provider sketch, so there was no bounded
  available-skills fragment, no source-owned `SKILL.md` read, and no place
  for warnings or per-turn selection state to live.
  
  This PR makes `ext/skills` the authority-preserving flow for listing
  candidate skills and injecting only explicitly selected main prompts,
  without adding more of that logic to `codex-core`.
  
  ## What changed
  
  - Expands catalog entries with `main_prompt`, display path, short
  description, dependency metadata, enabled/prompt visibility flags, and
  authority/package-aware read requests.
  - Replaces the placeholder `providers/*` modules with
  `SkillProviderSource` and `SkillProviders`, routing list/read/search
  calls by source kind and surfacing provider failures as warnings.
  - Adds bounded available-skills rendering and `SKILL.md` main-prompt
  truncation before the fragments enter model context.
  - Resolves explicit skill selections from structured `UserInput::Skill`,
  skill-file mentions, `skill://...` paths, and plain `$skill` text
  mentions, then reads selected prompts through their owning provider.
  - Stores mutable per-thread skills config and per-turn
  catalog/selection/warning state.
  - Adds `install_with_providers` so tests and future host wiring can
  supply concrete providers.
  
  ## Testing
  
  - Not run locally.
  - Added `codex-rs/ext/skills/tests/skills_extension.rs` coverage for
  available-catalog injection, selected prompt injection through the
  owning provider, and prompt-hidden skills that remain invokable.

  jif · 2026-06-03 16:24:16 +02:00
  96d2d2f68c
• fix: serialize goal progress accounting (#26155)

  ## Why
  
  Goal progress accounting can be reached from multiple completion paths
  for the same thread. Each path takes a progress snapshot, writes the
  usage delta, and then marks that snapshot as accounted. When two
  tool-completion hooks run at the same time, they can both observe the
  same unaccounted delta and charge it twice.
  
  ## What changed
  
  - Added a per-thread progress-accounting permit to
  `GoalAccountingState`.
  - Held that permit across the snapshot/write/mark-accounted critical
  section for active-turn, idle, and tool-finish accounting.
  - Added regression coverage for parallel tool-finish hooks so a shared
  token delta is charged once and only one progress event is emitted.
  
  ## Testing
  
  - Not run locally.
  - Added `parallel_tool_finish_accounts_active_goal_progress_once`.

  jif · 2026-06-03 15:10:16 +02:00
  7db18c8241
• skills: resolve per-turn catalogs from turn input context (#26106)

  ## Why
  
  The skills extension needs the resolved turn environments to build a
  real per-turn `SkillListQuery`. The previous `TurnLifecycleContributor`
  hook only had a turn id, so it could only seed a placeholder query and
  never carry the executor authorities that executor-scoped skill routing
  will need.
  
  Moving catalog resolution onto `TurnInputContributor` puts the skills
  extension on the same turn-preparation path that already has the
  environment ids and working directories for the submitted turn, while
  keeping the actual prompt injection work for follow-up changes.
  
  ## What changed
  
  - switch `ext/skills` from `TurnLifecycleContributor` to
  `TurnInputContributor`
  - build `executor_authorities` from `TurnInputContext.environments` and
  pass them through `SkillListQuery`
  - keep storing the resolved catalog in `SkillsTurnState`, but drop the
  placeholder query helper that no longer matches the real data flow
  - update the extension TODOs to reflect that per-turn catalog resolution
  now happens in the turn-input contributor, and that prompt/context
  injection still needs to move later
  
  ## Testing
  
  - Not run locally.

  jif · 2026-06-03 13:32:55 +02:00
  3389fa554e
• feat: add extension turn-input contributors (#25959)

  ## Disclaimer
  Do not use for now
  
  ## Why
  
  Extensions can already contribute prompt fragments and request same-turn
  item injection, but there was no host-owned hook for contributing
  structured `ResponseItem`s while Codex is assembling a new turn's
  initial model input. This change adds that seam so extensions can attach
  turn-local input that depends on the submitted user input and resolved
  turn environments without routing through prompt text or late injection.
  
  ## What changed
  
  - add `TurnInputContributor` to `codex_extension_api` and export the new
  `TurnInputContext` / `TurnInputEnvironment` types it receives
  - teach `ExtensionRegistry` to register and expose turn-input
  contributors alongside the existing extension hooks
  - call registered turn-input contributors from
  `core/src/session/turn.rs` while building the initial injected input for
  a turn, then append their returned `ResponseItem`s after the skill and
  plugin injections

  jif · 2026-06-03 01:33:31 +02:00
  271d5cecf2
• feat: add skills extension scaffold (#25953)

  ## Disclaimer
  This is only here for iteration purpose! Do not make any code rely on
  this
  
  ## Why
  
  Skills still live behind `codex-core` discovery and injection paths, but
  the extension system needs an authority-aware home before that logic can
  move. This adds that boundary without changing current skills behavior,
  and keeps host, executor, and remote skills distinct so future
  list/read/search flows do not collapse back to ambient local paths.
  
  ## What changed
  
  - Add the `codex-skills-extension` workspace/Bazel crate under
  `ext/skills`.
  - Define the initial catalog, authority, provider, and turn-state types
  for authority-bound skill packages and resources.
  - Register placeholder thread/config/prompt/turn lifecycle contributors
  plus host, executor, and remote provider aggregation points.
  - Capture the remaining extraction work as TODOs, including the missing
  extension API hooks needed for per-turn catalog construction and typed
  skill injection.
  - Keep plugins outside the runtime skills model: plugin-installed skills
  are treated as materialized host-owned skill sources once available.
  
  ## Verification
  
  - Not run locally.

  jif · 2026-06-03 01:10:26 +02:00
  2d385e166c
• Expose standalone image generation in code mode (#25923)

  ## Why
  
  Standalone image generation remained top-level-only in code-mode
  sessions.
  
  ## What changed
  
  - Change imagegen exposure from `DirectModelOnly` to `Direct`.
  - Keep direct-mode access while enabling nested code-mode access.
  - Add a focused regression test for the exposure contract.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`

  Won Park · 2026-06-02 22:27:52 +00:00
  bec21c7114
• Route standalone image generation through host finalization md (#25176)

  ## Why
  
  Standalone image-generation extensions emitted turn items through the
  low-level event path, bypassing host-owned finalization such as image
  persistence and contributor processing. At the same time, the
  generated-image save-path hint must remain visible to the model through
  the extension tool's `FunctionCallOutput`, rather than the legacy
  built-in developer-message path.
  
  ## What changed
  
  - Extended `ExtensionTurnItem` to support image-generation items while
  keeping the extension-facing emitter API limited to `emit_started` and
  `emit_completed`.
  - Routed extension completion through core `finalize_turn_item`, so
  standalone image-generation items receive host-owned processing and
  persisted `saved_path` values before publication.
  - Kept legacy built-in image generation on its existing
  developer-message hint path, while standalone image generation returns
  its deterministic saved-path hint in `FunctionCallOutput`.
  - Shared the image artifact path and output-hint formatting used by core
  and the image-generation extension.
  - Passed thread identity through extension tool calls so standalone
  image generation can construct the same intended artifact path as core.
  - Added an app-server integration test covering real standalone image
  generation, saved artifact publication, model-visible output hint
  wiring, and absence of the legacy developer-message hint.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-web-search-extension`
  - `just test -p codex-goal-extension`
  - `just test -p codex-memories-extension`
  - Targeted `codex-core` tests for image save history, extension
  completion finalization, and contributor execution
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`
  - `just fix -p codex-core`
  - `just fix -p codex-image-generation-extension`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  Won Park · 2026-06-02 12:00:04 -07:00
  57f337a8e9
• [codex] enable parallel standalone web search calls (#25702)

  ## Summary
  - opt the extension-backed standalone `web.run` tool into parallel tool
  execution
  - update the existing extension registration test to assert that the
  tool advertises parallel-call support
  
  ## Why
  The standalone web-search API endpoint now supports parallel requests.
  The extension executor still inherited the shared serial default,
  causing multiple `web.run` calls to acquire the exclusive runtime lock.
  
  ## Impact
  Models that emit multiple standalone web-search calls can now execute
  them concurrently when model-level parallel tool calls are enabled.
  
  ## Validation
  - `just fmt`
  - `just test -p codex-web-search-extension`
  - `git diff --check origin/main...HEAD`

  sayan-oai · 2026-06-01 15:04:11 -07:00
  b3c4157034
• Add goal extension GoalApi (#25096)

  ## Summary
  
  - add an extension-owned `GoalApi` for thread goal get/set/clear
  operations
  - register live goal runtimes with the API from the goal extension
  backend
  - cover the API and runtime-effect paths in goal extension tests
  
  ## Stack
  
  Follow-up app-server wiring PR: #25108
  
  ## Validation
  
  - `just fmt`
  - `just fix -p codex-goal-extension`
  - `just test -p codex-goal-extension`

  jif-oai · 2026-06-01 11:32:13 +02:00
  f27bbbd49c
• Use templates for goal steering prompts (#25576)

  ## Why
  
  Goal steering prompts have grown into long inline Rust strings, which
  makes the authored prompt text hard to review and easy to damage while
  changing the surrounding plumbing. Moving those prompts into embedded
  Markdown templates keeps the policy text in the shape reviewers actually
  read, while preserving the existing runtime substitution and objective
  escaping behavior.
  
  ## What changed
  
  - Added `ext/goal/templates/goals/continuation.md`, `budget_limit.md`,
  and `objective_updated.md` for the three goal steering prompts.
  - Updated `ext/goal/src/steering.rs` to parse those embedded templates
  once with `codex-utils-template` and render the existing goal values
  into them.
  - Kept user objectives XML-escaped before rendering and converted budget
  counters into template variables.
  - Added the template directory to `ext/goal/BUILD.bazel` `compile_data`
  so Bazel has the same embedded prompt inputs as Cargo.
  
  ## Testing
  
  - Not run locally.

  jif-oai · 2026-06-01 10:55:14 +02:00
  c875bc8a33
• Add goal extension idle continuation (#25060)

  ## Why
  
  The goal extension needs a way to resume an active goal after the thread
  becomes idle, but the old core goal runtime should not be refactored as
  part of this step. The missing piece is a small core-owned turn-start
  primitive: let an extension ask for a normal model turn only when the
  thread is idle, and otherwise fail without injecting into whatever is
  currently active.
  
  ## What Changed
  
  - Adds `CodexThread::try_start_turn_if_idle(...)` as the narrow
  extension-facing primitive for synthetic idle work.
  - Implements the session side so it refuses to start when:
    - the provided input is empty,
    - the session is in plan mode,
    - a turn is already active, or
    - trigger-turn mailbox work is pending.
  - Gives trigger-turn mailbox work priority if it appears while the idle
  turn is being prepared.
  - Wires `GoalExtension::on_thread_idle` to read the active persisted
  goal and submit the continuation prompt through this idle-only
  primitive.
  - Keeps the legacy core goal continuation implementation in place
  instead of folding it into this PR.
  
  ## Behavior
  
  This is intentionally best-effort. If `try_start_turn_if_idle` observes
  that the thread is not idle, or that higher-priority mailbox work should
  run first, it returns the input to the caller. The goal extension drops
  that continuation prompt and waits for a future idle opportunity instead
  of injecting stale synthetic goal text into an active turn.
  
  ## Validation
  
  - `just test -p codex-core
  try_start_turn_if_idle_rejects_active_turn_without_injecting`
  - `just test -p codex-goal-extension`

  jif-oai · 2026-06-01 10:42:01 +02:00
  f1b1b64005
• [codex] Require model for standalone web search (#25131)

  ## Why
  
  The standalone `/v1/alpha/search` request now requires a `model`, but
  the `web.run` extension currently omits it.
  
  Adds `model` to extension `ToolCall` invocation.
  
  Follow-up to #23823.
  
  ## What changed
  
  - Make `SearchRequest.model` required.
  - Expose the effective per-turn model on extension tool calls and pass
  it in standalone web-search requests.
  - Assert the model is forwarded in the app-server round-trip test.
  
  ## Testing
  
  - `just test -p codex-api -p codex-tools -p codex-web-search-extension
  -p codex-memories-extension -p codex-goal-extension`
  - `just test -p codex-core -E
  'test(passes_turn_fields_and_scoped_turn_item_emitter_to_extension_call)'`
  - `just test -p codex-app-server -E
  'test(standalone_web_search_round_trips_encrypted_output)'`

  sayan-oai · 2026-05-29 12:03:04 -07:00
  1f93706e99
• Route extension image generation through the native image completion pipeline (#24972)

  ## Why
  
  The standalone `image_gen.imagegen` extension should behave like native
  image generation for artifact persistence and UI completion, while
  returning its save-location guidance as part of the tool result instead
  of injecting a developer message.
  
  ## What Changed
  
  - Added an image-generation completion hook for extension tools so core
  can persist generated images and emit the existing `ImageGeneration`
  lifecycle events.
  - Reused core image artifact persistence for extension output and
  removed extension-local save-path/file-writing logic.
  - Split shared image persistence from built-in finalization so native
  image generation keeps its existing developer-message instruction
  behavior.
  - Returned the generated image save-location instruction through the
  extension `FunctionCallOutput`, alongside the generated image input for
  model follow-up.
  - Preserved the existing image-generation event shape for current UI and
  replay compatibility.
  - Avoided cloning the full generated-image base64 payload when emitting
  the in-progress image item.
  - Removed dependencies no longer needed after moving persistence out of
  the extension crate.
  
  ## Fast Follow
  - Adjust the existing Extension API and add a general `TurnItem`
  finalization path for re-usability of code
  
  ## Validation
  
  - Ran `just fmt`.
  - Ran `just bazel-lock-update`.
  - Ran `just bazel-lock-check`.
  - Ran `just test -p codex-tools -p codex-extension-api -p
  codex-image-generation-extension`.
  - Ran `just test -p codex-core
  image_generation_publication_is_finalized_by_core`.
  - Ran `just test -p codex-core
  handle_output_item_done_records_image_save_history_message`.
  - Ran `just fix -p codex-tools -p codex-extension-api -p codex-core -p
  codex-image-generation-extension`.

  Won Park · 2026-05-29 17:33:13 +00:00
  10b0399034
• Show activity for standalone web search calls (#24693)

  ## Why
  
  Standalone `web.run` calls run in the extension, so they need normal
  web-search progress activity while a request is in flight and durable
  completed activity after a thread is reloaded.
  
  Follow-up to #23823; uses the extension turn-item emission path added in
  #24813.
  
  ## What changed
  
  - Emit standalone `web.run` start/completion items through the host
  turn-item emitter, preserving standard client delivery and rollout
  persistence.
  - Include useful completion detail for queries, image queries, and
  literal-URL `open`/`find` commands.
  - Render completed searches as `Searched the web` or `Searched the web
  for <detail>`, with snapshot coverage for the detail-free case.
  - Extend the app-server round-trip test to verify completed search
  activity is reconstructed by `thread/read` after a fresh-process reload.
  
  ## Testing
  
  - `just test -p codex-web-search-extension`
  - `just test -p codex-app-server -E
  "test(standalone_web_search_round_trips_encrypted_output)"`

  sayan-oai · 2026-05-29 16:12:58 +00:00
  96f1347fa3
• Handle goal usage limits from turn errors (#25095)

  ## Summary
  - handle goal usage-limit turn errors in the goal extension
  - exercise the extension path in the goal backend test
  
  ## Tests
  - just fmt
  - just test -p codex-goal-extension
  - just fix -p codex-goal-extension

  jif-oai · 2026-05-29 15:39:05 +02:00
  27e256bc40
• Use inject_if_running for active goal steering (#24924)

  ## Why
  
  This PR is stacked on #24918, which moves goal steering onto
  source-labeled internal model context fragments. Active-turn goal
  steering should use the same running-turn injection path as other
  runtime steering, so those fragments enter the pending input queue as
  `ResponseItem`s through the existing
  [`Session::inject_if_running`](https://github.com/openai/codex/blob/8d6f6cdf69b055c27682e7cdea9caf72a3e2ee7f/codex-rs/core/src/session/inject.rs#L12-L27)
  behavior instead of through a goal-specific conversion wrapper.
  
  ## What Changed
  
  - Exposes a narrow `CodexThread::inject_if_running` bridge for callers
  that only hold a thread handle.
  - Changes `ext/goal` active-turn steering to pass `ResponseItem`s
  directly.
  - Builds goal steering prompts as contextual internal model context
  `ResponseItem`s before injecting them into the running turn.
  
  ## Testing
  
  Not run locally; PR metadata update only.

  jif-oai · 2026-05-29 11:24:39 +02:00
  8f6a945ec9
• Use internal model context fragments for goal steering (#24918)

  ## Why
  
  Goal steering is one form of runtime-owned model context, but the old
  `<goal_context>` wrapper made the contextual-fragment hiding path
  goal-specific. Using a source-labeled internal context fragment gives
  core and extensions a shared shape for hidden model steering while
  keeping those prompts out of visible turn history.
  
  The change also keeps legacy `<goal_context>` messages recognized as
  hidden contextual input so existing stored history does not start
  rendering old goal-steering prompts as user-visible turn items.
  
  ## What Changed
  
  - Replaces `GoalContext` with `InternalModelContextFragment` plus a
  validated `InternalContextSource`.
  - Renders goal steering as `<codex_internal_context
  source="goal">...</codex_internal_context>`.
  - Updates core goal steering and `ext/goal` steering to inject the new
  internal-context fragment.
  - Updates contextual-fragment, event-mapping, goal, and session tests
  for the new wrapper.
  
  ## Test Coverage
  
  - Adds coverage for detecting the new internal model context fragment.
  - Preserves coverage for hiding legacy `<goal_context>` fragments.
  - Verifies invalid internal context sources are rejected and arbitrary
  context tags are not hidden.
  - Updates goal steering/session assertions to expect the new
  `source="goal"` wrapper.

  jif-oai · 2026-05-29 10:28:25 +02:00
  740d942f90
• Add feature-gated standalone image generation extension (#24723)

  ## Why
  
  Add a standalone image generation path that can be exercised
  independently of hosted Responses image generation, while retaining the
  hosted tool as fallback unless the extension is actually available to
  the model.
  
  ## What changed
  
  - Added the `codex-image-generation-extension` crate with standalone
  generate/edit execution, prior-image selection for edits, model-visible
  image output, and local generated-image persistence.
  - Installed the extension in app-server behind the disabled-by-default
  `imagegenext` feature and backend eligibility checks.
  - Updated core tool planning so eligible `image_gen.imagegen` exposure
  replaces hosted `image_generation`, while unavailable configurations
  retain hosted fallback.
  - Added coverage for extension behavior, edit history reuse, feature
  gating, auth eligibility, and hosted-tool replacement.
  - The extension is installed through app-server only in this PR; other
  execution paths retain hosted image generation because hosted
  replacement occurs only when the standalone executor is actually
  registered and model-visible.
  - The initial extension contract intentionally fixes the image model to
  `gpt-image-2` and uses automatic image parameters.
  - Native generated-image history/card parity and rollout persistence
  cleanup are intentionally deferred follow-up work.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-features`
  - `just test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`
  - `just test -p codex-app-server`
  - `just fix -p codex-image-generation-extension -p codex-features -p
  codex-core -p codex-app-server`
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Won Park · 2026-05-28 11:44:55 -07:00
  ecb41fcb64
• 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
• Gate goal tools by thread eligibility (#24925)

  ## Why
  
  Goal tools create and update goal state for a persistent thread. The
  extension was only checking whether goals were enabled before
  advertising those tools, which meant they could be surfaced in contexts
  that should not receive thread goal controls: ephemeral threads without
  persistent thread state and review subagents.
  
  Those sessions can still run the goal extension lifecycle, but the
  thread tools should only be visible when the current thread can safely
  use them.
  
  ## What changed
  
  - Adds a `GoalRuntimeConfig` that separates goal enablement from whether
  goal tools are available for the current thread.
  - Computes tool eligibility on thread start from
  `persistent_thread_state_available` and `SessionSource`, hiding tools
  for review subagents.
  - Uses `GoalRuntimeHandle::tools_visible()` when contributing thread
  tools so enabled runtime state does not automatically imply tool
  exposure.
  - Adds backend coverage for hiding goal tools on ephemeral threads and
  review subagents.
  
  ## Testing
  
  - Added `goal_tools_hidden_for_ephemeral_threads`.
  - Added `goal_tools_hidden_for_review_subagents`.

  jif-oai · 2026-05-28 17:47:17 +02:00
  e426d48f6d
• 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
• Fix memories namespace for Responses API tools (#24898)

  ## Why
  
  Dedicated memories tools are exposed through a Responses API namespace
  tool. The namespace itself has to be a valid tool identifier, so
  `memories/` can fail validation before the model ever gets a chance to
  call the memory tools.
  
  ## What changed
  
  - Changed `MEMORY_TOOLS_NAMESPACE` from `memories/` to `memories`.
  - Added `memory_tool_namespace_matches_responses_api_identifier` so the
  namespace stays non-empty and limited to Responses-safe identifier
  characters.
  
  ## Verification
  
  - Added unit coverage for the namespace identifier shape in
  `codex-rs/ext/memories/src/tests.rs`.

  jif-oai · 2026-05-28 14:06:21 +02:00
  ba6678ca9a
• 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
• feat: handle goal usage limits in goal extension (#24628)

  ## Why
  
  The extracted goal runtime needs a host-callable path for turns that
  stop because the workspace usage limit is reached. In that case, any
  in-turn goal progress should be accounted before the goal becomes
  terminal, and active goal accounting must be cleared so later
  tool-finish or turn-stop handling does not keep charging usage to a
  stopped goal.
  
  ## What changed
  
  - Adds `GoalRuntimeHandle::usage_limit_active_goal_for_turn`, which
  accounts current active-goal progress, marks the active or
  budget-limited thread goal as `UsageLimited`, records terminal metrics
  when the status changes, clears active goal accounting, and emits the
  updated goal event.
  - Covers both active and budget-limited goals in
  `ext/goal/tests/goal_extension_backend.rs`, including the invariant that
  later token/tool events do not add usage after the goal has been
  usage-limited.
  
  ## Testing
  
  - Added
  `usage_limit_active_goal_accounts_progress_and_clears_accounting`.
  - Added `usage_limit_budget_limited_goal_accounts_remaining_progress`.

  jif-oai · 2026-05-27 13:00:06 +02:00
  bc005029bd
• 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
• make direct only allowed caller for standalone websearch (#24646)

  only allow `Direct` callers of the standalone websearch tool because its
  not supported in codemode

  sayan-oai · 2026-05-26 21:05:40 +00:00
  66ff8b0f54
• Add experimental turn additional context (#24154)

  ## Summary
  
  Adds experimental `additionalContext` support to `turn/start` and
  `turn/steer` so clients can provide ephemeral external context, such as
  browser or automation state, without turning that plumbing into a
  visible user prompt or triggering user-prompt lifecycle behavior.
  
  ## API Shape
  
  The parameter shape is:
  
  ```ts
  additionalContext?: Record<string, {
    value: string
    kind: "untrusted" | "application"
  }> | null
  ```
  
  Example:
  
  ```json
  {
    "additionalContext": {
      "browser_info": {
        "value": "Active tab is CI failures.",
        "kind": "untrusted"
      },
      "automation_info": {
        "value": "CI rerun is in progress.",
        "kind": "application"
      }
    }
  }
  ```
  
  The keys are opaque and caller-defined.
  
  ## Context Injection
  
  When provided, accepted entries are inserted into model context as
  hidden contextual message items, not as visible thread user-message
  items.
  
  `kind: "untrusted"` entries are inserted with role `user`:
  
  ```text
  <external_${key}>${value}</external_${key}>
  ```
  
  `kind: "application"` entries are inserted with role `developer`:
  
  ```text
  <${key}>${value}</${key}>
  ```
  
  Values are not escaped. Each value is truncated to 1k approximate tokens
  before wrapping.
  
  For `turn/start`, accepted additional context is inserted before normal
  user input. For `turn/steer`, additional context is merged only when the
  steer includes non-empty user input; context-only steers still reject as
  empty input.
  
  ## Dedupe Strategy
  
  `AdditionalContextStore` lives on session state and stores the latest
  complete additional-context map.
  
  Each `turn/start` or non-empty `turn/steer` treats its
  `additionalContext` as the current complete set of values. Entries are
  injected only when the key is new or the exact entry for that key
  changed, including `value` or `kind`. After merging, the store is
  replaced with the provided map, so omitted keys are removed from the
  retained set and can be injected again later if reintroduced.
  
  Omitting `additionalContext`, passing `null`, or passing an empty object
  resets the store to empty and injects nothing.
  
  ## What Changed
  
  - Threads experimental v2 `additionalContext` through app-server into
  core turn start and steer handling.
  - Adds separate contextual fragment types for untrusted user-role
  context and application developer-role context.
  - Uses pending response input items so additional context can be
  combined with normal user input without treating it as prompt text.
  - Adds integration coverage for start/steer flow, role routing,
  dedupe/reset behavior, deletion/re-add behavior, hook-blocked input
  behavior, empty context-only steer rejection, external-fragment marker
  matching, and truncation.

  pakrym-oai · 2026-05-26 13:02:34 -07:00
  768848ab6f
• standalone websearch extension (#23823)

  ## Summary
  
  Add the extension-backed standalone `web.run` tool so Codex can call the
  standalone search endpoint through the `codex-api` search client and
  return its encrypted output to Responses.
  
  - gate the new tool behind `standalone_web_search`
  - install the extension in the app-server thread registry and hide
  hosted `web_search` when standalone search is enabled for OpenAI
  providers so the two paths stay mutually exclusive
  - build search context from persisted history using a small tail
  heuristic: previous user message, assistant text between the last two
  user turns capped at about 1k tokens, and current user message
  
  ## Test Plan
  
  - `cargo test -p codex-web-search-extension`
  - `cargo test -p codex-api`
  - `cargo test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`

  sayan-oai · 2026-05-26 11:12:24 -07:00
  a22706dfae
• fix: restore goal accounting after thread resume (#24626)

  ## Why
  
  Goal idle accounting is supposed to survive a thread resume. Previously,
  the resume hook restored the active goal state inline from the extension
  lifecycle contributor, which left the runtime handle without a reusable
  restoration path and made the behavior hard to cover directly. When a
  thread with an active goal was resumed, goal accounting could lose track
  of the active idle goal instead of continuing to accrue elapsed time.
  
  ## What changed
  
  - Moved thread-resume restoration into
  `GoalRuntimeHandle::restore_after_resume()` so the runtime owns
  rehydrating active goal accounting from persisted thread goal state.
  - Kept disabled goal runtimes as a no-op and preserved the existing
  warning path when persisted goal state cannot be loaded.
  - Added a backend regression test that seeds an active goal, resumes the
  thread, waits briefly, and verifies elapsed idle time is reflected on
  the next external goal mutation.
  
  ## Testing
  
  - Not run locally; this metadata update only rewrote the PR title/body.

  jif-oai · 2026-05-26 20:01:13 +02:00
  823381e867
• Add goal extension telemetry parity (#24615)

  ## Why
  
  `core/src/goals.rs` already emits OTEL metrics for goal creation,
  resume, terminal transitions, token counts, and duration. As `/goal`
  moves into `ext/goal`, the extension needs to preserve that telemetry
  contract instead of only emitting app-visible `ThreadGoalUpdated`
  events.
  
  This keeps the existing `codex.goal.*` metric surface intact while goal
  lifecycle ownership shifts toward the extension.
  
  ## What changed
  
  - Added an extension-local `GoalMetrics` helper that records the
  existing `codex.goal.*` counters and histograms through `codex-otel`.
  - Threaded an optional `MetricsClient` through `install_with_backend`,
  `GoalExtension`, `GoalRuntimeHandle`, and `GoalToolExecutor`.
  - Emitted created, resumed, and terminal goal metrics from the extension
  paths that create goals, restore active goals on thread resume, account
  budget limits, complete or block goals, and handle external goal
  mutations.
  - Updated existing goal extension test setup callsites to pass `None`
  for metrics when instrumentation is not under test.
  
  ## Verification
  
  Not run locally.

  jif-oai · 2026-05-26 19:48:32 +02:00
  08504e86fb
• feat: gate dedicated memories tools in config (#24600)

  ## Why
  
  The memories extension already has dedicated `list`, `read`, `search`,
  and `add_ad_hoc_note` tools, but app-server registration was still
  disabled. The memories app collaborator needs an explicit config switch
  so those native extension tools can be exposed intentionally, without
  making ordinary memory prompt usage automatically register the dedicated
  tool surface.
  
  ## What changed
  
  - Added `[memories].dedicated_tools`, defaulting to `false`, to
  `MemoriesToml` / `MemoriesConfig`.
  - Regenerated `core/config.schema.json` for the new setting.
  - Registered the memories extension as a `ToolContributor`, while
  keeping tool contribution gated on both memories being enabled and
  `dedicated_tools = true`.
  - Added tests for the disabled default, the enabled dedicated-tools
  path, and installer registration.
  
  ## Verification
  
  - `just test -p codex-config -p codex-memories-extension`

  jif-oai · 2026-05-26 18:18:58 +02:00
  ef6528c6c7
• Add memory tool call metrics to memories extension (#24583)

  ## Why
  
  The memories extension now receives a metrics exporter, but the useful
  extension-owned signal is the memory tool call itself: which operation
  ran, which memory area it touched, whether the backend call succeeded,
  and whether the result was truncated.
  
  ## What changed
  
  - Added the `codex.memories.tool.call` counter in
  `ext/memories/src/metrics.rs`.
  - Emit that counter from `memories/add_ad_hoc_note`, `memories/list`,
  `memories/read`, and `memories/search` after backend execution.
  - Tag each call with `tool`, `operation`, `scope`, `status`, and
  `truncated`.
  - Pass the existing `MetricsClient` through the memories extension into
  the tool executors; tests use `None`.
  
  ## Verification
  
  - `just test -p codex-memories-extension`

  jif-oai · 2026-05-26 15:27:51 +02:00
  01a8bf0ae3
• Wire metrics client into memories extension (#24567)

  ## Summary
  
  - let the memories extension capture the process-global OTEL metrics
  client at install time
  - keep app-server/TUI/exec extension construction APIs unchanged
  - store the metrics client for future memory metrics without emitting
  any metrics yet
  
  ## Test plan
  
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - Not run: tests/clippy per request; CI will cover them

  jif-oai · 2026-05-26 13:56:46 +02:00
  c37884d5eb
• Add ad-hoc memory note tool (#24562)

  ## Why
  
  Codex memory updates currently rely on instructions that tell agents to
  create ad-hoc note files directly in the memory workspace. The memories
  extension already has a `MemoriesBackend` abstraction for local storage
  and future non-filesystem backends, so the ad-hoc note writer should
  live behind that same interface instead of baking local filesystem
  assumptions into the tool shape.
  
  ## What
  
  - Adds a `memories/add_ad_hoc_note` tool to the existing memories tool
  bundle.
  - Extends `MemoriesBackend` with `add_ad_hoc_note` plus request/response
  types so remote memory stores can implement the same operation later.
  - Implements the local backend by creating append-only notes under
  `extensions/ad_hoc/notes`.
  - Validates the tool-provided filename contract
  (`YYYY-MM-DDTHH-MM-SS-<slug>.md`), rejects path-like filenames, rejects
  empty notes, and uses create-new semantics so existing notes are never
  overwritten.
  - Keeps memories tool contribution behind the existing commented-out
  registration path; this defines the tool surface without newly exposing
  it through app-server.
  
  ## Test Plan
  
  - `just test -p codex-memories-extension`

  jif-oai · 2026-05-26 12:23:24 +02:00
  3936ed221d
• chore: move memory prompt builder into extension (#24558)

  ## Why
  
  The memories extension now owns the read-path developer instructions it
  injects at thread start. Keeping that prompt builder and template in
  `codex-memories-read` left the extension depending on a helper crate for
  extension-specific prompt assembly, and kept async template/truncation
  dependencies in the read crate after the remaining read surface no
  longer needed them.
  
  ## What changed
  
  - Moved `prompts.rs`, its tests, and `templates/memories/read_path.md`
  from `memories/read` into `ext/memories`.
  - Wired `MemoryExtension` to call the local prompt builder and added the
  moved templates to `ext/memories/BUILD.bazel` compile data.
  - Removed the now-unused prompt export and prompt-related dependencies
  from `codex-memories-read`.
  
  ## Testing
  
  - Not run locally.

  jif-oai · 2026-05-26 11:53:47 +02:00
  de513a83f3
• [wip] goal shift (#23858)
  jif-oai · 2026-05-26 11:22:18 +02:00
  7f9ab6e083
• 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
• Make tool executor specs mandatory (#23870)

  ## Why
  
  `ToolExecutor` is the runtime contract that keeps a callable tool and
  its model-visible spec together. Leaving `spec()` optional lets a
  registered runtime silently omit that half of the contract, and it also
  overloads a missing spec as an exposure decision for tools that should
  stay dispatchable without being shown to the model.
  
  ## What
  
  - Make `ToolExecutor::spec()` required and update core, extension, and
  test tool executors to return a concrete `ToolSpec`.
  - Add `ToolExposure::Hidden` for dispatch-only tools. The legacy
  `shell_command` runtime in unified-exec sessions now uses that explicit
  exposure instead of hiding itself by omitting a spec.
  - Build MCP tool specs when `McpHandler` is constructed so invalid MCP
  specs are skipped before the handler is registered.
  - Keep tool planning aligned with the new contract for direct, deferred,
  hidden, code-mode, dynamic, and namespaced tool paths.
  
  ## Testing
  
  - Added tool-plan coverage that invalid MCP tool specs are not
  registered.
  - Updated shell-family coverage for the hidden legacy `shell_command`
  runtime and the affected tool executor test fixtures.

  jif-oai · 2026-05-21 15:25:56 +02:00
  516f134641
• [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
• Fix thread settings clippy failure (#23724)

  ## Why
  
  `main` picked up two small Rust build failures after nearby merges:
  
  - #23507 added a real handler for
  `ServerNotification::ThreadSettingsUpdated`, but the same variant was
  still listed in the ignored-notification match arm. Full Clippy runs
  treat the resulting unreachable-pattern warning as an error.
  - #23666 added `turn_id` and `truncation_policy` to
  `codex_tools::ToolCall`, while the goal extension backend test fixtures
  from the goal-extension work still used the old shape. That left
  `codex-goal-extension` tests unable to compile once the branches met on
  `main`.
  
  ## What changed
  
  Removed the duplicate `ThreadSettingsUpdated` match pattern from
  `tui/src/chatwidget/protocol.rs`.
  
  Updated the goal extension test `tool_call` helper to populate the new
  `ToolCall` fields, and reused that helper for the one direct literal
  that still had the old field list.
  
  ## Verification
  
  - `just fix -p codex-tui`
  - `cargo test -p codex-goal-extension`

  Eric Traut · 2026-05-20 11:58:23 -07:00
  7c3cc1db81
• [codex] Preserve failed goal accounting flushes (#23717)

  ## What
  - Preserve database accounting failures from the goal extension instead
  of collapsing them into `None`
  - Warn with turn/tool context when a flush fails
  - Keep stop/abort accounting snapshots alive when the final flush did
  not persist
  
  ## Why
  PR #23696 can finish and discard a turn snapshot after
  `account_thread_goal_usage` fails. That loses the final accumulated
  accounting state silently. This follow-up keeps that failure explicit
  and avoids deleting the local snapshot in the failing path.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-goal-extension`

  jif-oai · 2026-05-20 20:37:27 +02:00
  d84b824d53
• feat: add turn_id and truncation_policy to extension tool calls (#23666)

  ## Why
  
  Extension-owned tools currently receive a stripped `ToolCall` with only
  `call_id`, `tool_name`, and `payload`.
  That makes extension work that needs turn-local execution context
  awkward, especially web-search extension work that needs the active
  `truncation_policy` at tool invocation time.
  
  Reconstructing that value from config or `ExtensionData` would be
  indirect and could drift from the actual turn context, so the cleaner
  fix is to pass the needed turn metadata directly on the extension-facing
  invocation type.
  
  ## What changed
  
  - added `turn_id` and `truncation_policy` to `codex_tools::ToolCall`
  - populated those fields when core adapts `ToolInvocation` into an
  extension tool call
  - added a focused adapter test that verifies extension executors receive
  the forwarded turn metadata
  - updated the memories extension tests to construct the richer
  `ToolCall`
  - added the `codex-utils-output-truncation` dependency to `codex-tools`
  and refreshed lockfiles
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-memories-extension`
  - `cargo test -p codex-core passes_turn_fields_to_extension_call`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  jif-oai · 2026-05-20 20:14:41 +02:00
  c5bd131567
• feat: account active goal progress in the goal extension (#23696)

  ## Why
  
  The goal extension can create and surface goals, but the live
  turn-accounting path still stopped short of persisting active-goal
  progress. That leaves token and wall-clock usage, plus
  `ThreadGoalUpdated` events, out of sync with the extension boundary once
  work actually advances or a goal transitions out of active state.
  
  ## What changed
  
  - Teach `GoalAccountingState` to track the current turn, active goal,
  token deltas, and wall-clock progress snapshots against the persisted
  goal id.
  - Flush active-goal accounting from tool-finish, turn-stop, and
  turn-abort lifecycle hooks, and emit `ThreadGoalUpdated` events when
  persisted progress changes.
  - Route `create_goal` and `update_goal` through the same accounting
  state so new goals start from the right baseline, final progress is
  flushed before status changes, and `update_goal` can mark a goal
  `blocked` as well as `complete`.
  - Keep budget-limited goals accruing through the end of the turn while
  clearing local active-goal state once a turn or explicit update is
  finished.
  - Expand backend and lifecycle coverage around store ids, baseline
  reset, tool-finish accounting, budget-limited carry-through, and
  blocked-goal updates.
  
  ## Testing
  
  - Added focused backend coverage in
  `codex-rs/ext/goal/tests/goal_extension_backend.rs` for baseline reset,
  tool-finish accounting, budget-limited turns, and blocked-goal updates.
  - Extended `codex-rs/core/src/session/tests.rs` to assert that lifecycle
  inputs expose the expected session, thread, and turn store ids.

  jif-oai · 2026-05-20 18:36:37 +02:00
  d4f842f3b3
• 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