429 Commits

• [stack 4/4] Reduce realtime self-interruptions during playback (#14827)

  ## Stack Position
  4/4. Top-of-stack sibling built on #14830.
  
  ## Base
  - #14830
  
  ## Sibling
  - #14829
  
  ## Scope
  - Gate low-level mic chunks while speaker playback is active, while
  still allowing spoken barge-in.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-17 05:19:51 +00:00
  32e4a5d5d9
• [stack 2/4] Align main realtime v2 wire and runtime flow (#14830)

  ## Stack Position
  2/4. Built on top of #14828.
  
  ## Base
  - #14828
  
  ## Unblocks
  - #14829
  - #14827
  
  ## Scope
  - Port the realtime v2 wire parsing, session, app-server, and
  conversation runtime behavior onto the split websocket-method base.
  - Branch runtime behavior directly on the current realtime session kind
  instead of parser-derived flow flags.
  - Keep regression coverage in the existing e2e suites.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-16 21:38:07 -07:00
  fbd7f9b986
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• Reuse guardian session across approvals (#14668)

  ## Summary
  - reuse a guardian subagent session across approvals so reviews keep a
  stable prompt cache key and avoid one-shot startup overhead
  - clear the guardian child history before each review so prior guardian
  decisions do not leak into later approvals
  - include the `smart_approvals` -> `guardian_approval` feature flag
  rename in the same PR to minimize release latency on a very tight
  timeline
  - add regression coverage for prompt-cache-key reuse without
  prior-review prompt bleed
  
  ## Request
  - Bug/enhancement request: internal guardian prompt-cache and latency
  improvement request
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-15 22:56:18 -07:00
  6fdeb1d602
• Preserve background terminals on interrupt and rename cleanup command to /stop (#14602)

  ### Motivation
  - Interrupting a running turn (Ctrl+C / Esc) currently also terminates
  long‑running background shells, which is surprising for workflows like
  local dev servers or file watchers.
  - The existing cleanup command name was confusing; callers expect an
  explicit command to stop background terminals rather than a UI clear
  action.
  - Make background‑shell termination explicit and surface a clearer
  command name while preserving backward compatibility.
  
  ### Description
  - Renamed the background‑terminal cleanup slash command from `Clean`
  (`/clean`) to `Stop` (`/stop`) and kept `clean` as an alias in the
  command parsing/visibility layer, updated the user descriptions and
  command popup wiring accordingly.
  - Updated the unified‑exec footer text and snapshots to point to `/stop`
  (and trimmed corresponding snapshot output to match the new label).
  - Changed interrupt behavior so `Op::Interrupt` (Ctrl+C / Esc interrupt)
  no longer closes or clears tracked unified exec / background terminal
  processes in the TUI or core cleanup path; background shells are now
  preserved after an interrupt.
  - Updated protocol/docs to clarify that `turn/interrupt` (or
  `Op::Interrupt`) interrupts the active turn but does not terminate
  background terminals, and that `thread/backgroundTerminals/clean` is the
  explicit API to stop those shells.
  - Updated unit/integration tests and insta snapshots in the TUI and core
  unified‑exec suites to reflect the new semantics and command name.
  
  ### Testing
  - Ran formatting with `just fmt` in `codex-rs` (succeeded). 
  - Ran `cargo test -p codex-protocol` (succeeded). 
  - Attempted `cargo test -p codex-tui` but the build could not complete
  in this environment due to a native build dependency that requires
  `libcap` development headers (the `codex-linux-sandbox` vendored build
  step); install `libcap-dev` / make `libcap.pc` available in
  `PKG_CONFIG_PATH` to run the TUI test suite locally.
  - Updated and accepted the affected `insta` snapshots for the TUI
  changes so visual diffs reflect the new `/stop` wording and preserved
  interrupt behavior.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_69b39c44b6dc8323bd133ae206310fae)

  friel-openai · 2026-03-15 22:17:25 -07:00
  ba463a9dc7
• Fix Windows CI assertions for guardian and Smart Approvals (#14645)

  - Normalize guardian assessment path serialization to use forward
  slashes for cross-platform stability.
  - Seed workspace-write defaults in the Smart Approvals
  override-turn-context test so Windows and non-Windows selection flows
  are consistent.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: Charles Cunningham <ccunningham@openai.com>

  Ahmed Ibrahim · 2026-03-14 02:15:58 +00:00
  69c8a1ef9e
• Add Smart Approvals guardian review across core, app-server, and TUI (#13860)

  ## Summary
  - add `approvals_reviewer = "user" | "guardian_subagent"` as the runtime
  control for who reviews approval requests
  - route Smart Approvals guardian review through core for command
  execution, file changes, managed-network approvals, MCP approvals, and
  delegated/subagent approval flows
  - expose guardian review in app-server with temporary unstable
  `item/autoApprovalReview/{started,completed}` notifications carrying
  `targetItemId`, `review`, and `action`
  - update the TUI so Smart Approvals can be enabled from `/experimental`,
  aligned with the matching `/approvals` mode, and surfaced clearly while
  reviews are pending or resolved
  
  ## Runtime model
  This PR does not introduce a new `approval_policy`.
  
  Instead:
  - `approval_policy` still controls when approval is needed
  - `approvals_reviewer` controls who reviewable approval requests are
  routed to:
    - `user`
    - `guardian_subagent`
  
  `guardian_subagent` is a carefully prompted reviewer subagent that
  gathers relevant context and applies a risk-based decision framework
  before approving or denying the request.
  
  The `smart_approvals` feature flag is a rollout/UI gate. Core runtime
  behavior keys off `approvals_reviewer`.
  
  When Smart Approvals is enabled from the TUI, it also switches the
  current `/approvals` settings to the matching Smart Approvals mode so
  users immediately see guardian review in the active thread:
  - `approval_policy = on-request`
  - `approvals_reviewer = guardian_subagent`
  - `sandbox_mode = workspace-write`
  
  Users can still change `/approvals` afterward.
  
  Config-load behavior stays intentionally narrow:
  - plain `smart_approvals = true` in `config.toml` remains just the
  rollout/UI gate and does not auto-set `approvals_reviewer`
  - the deprecated `guardian_approval = true` alias migration does
  backfill `approvals_reviewer = "guardian_subagent"` in the same scope
  when that reviewer is not already configured there, so old configs
  preserve their original guardian-enabled behavior
  
  ARC remains a separate safety check. For MCP tool approvals, ARC
  escalations now flow into the configured reviewer instead of always
  bypassing guardian and forcing manual review.
  
  ## Config stability
  The runtime reviewer override is stable, but the config-backed
  app-server protocol shape is still settling.
  
  - `thread/start`, `thread/resume`, and `turn/start` keep stable
  `approvalsReviewer` overrides
  - the config-backed `approvals_reviewer` exposure returned via
  `config/read` (including profile-level config) is now marked
  `[UNSTABLE]` / experimental in the app-server protocol until we are more
  confident in that config surface
  
  ## App-server surface
  This PR intentionally keeps the guardian app-server shape narrow and
  temporary.
  
  It adds generic unstable lifecycle notifications:
  - `item/autoApprovalReview/started`
  - `item/autoApprovalReview/completed`
  
  with payloads of the form:
  - `{ threadId, turnId, targetItemId, review, action? }`
  
  `review` is currently:
  - `{ status, riskScore?, riskLevel?, rationale? }`
  - where `status` is one of `inProgress`, `approved`, `denied`, or
  `aborted`
  
  `action` carries the guardian action summary payload from core when
  available. This lets clients render temporary standalone pending-review
  UI, including parallel reviews, even when the underlying tool item has
  not been emitted yet.
  
  These notifications are explicitly documented as `[UNSTABLE]` and
  expected to change soon.
  
  This PR does **not** persist guardian review state onto `thread/read`
  tool items. The intended follow-up is to attach guardian review state to
  the reviewed tool item lifecycle instead, which would improve
  consistency with manual approvals and allow thread history / reconnect
  flows to replay guardian review state directly.
  
  ## TUI behavior
  - `/experimental` exposes the rollout gate as `Smart Approvals`
  - enabling it in the TUI enables the feature and switches the current
  session to the matching Smart Approvals `/approvals` mode
  - disabling it in the TUI clears the persisted `approvals_reviewer`
  override when appropriate and returns the session to default manual
  review when the effective reviewer changes
  - `/approvals` still exposes the reviewer choice directly
  - the TUI renders:
  - pending guardian review state in the live status footer, including
  parallel review aggregation
    - resolved approval/denial state in history
  
  ## Scope notes
  This PR includes the supporting core/runtime work needed to make Smart
  Approvals usable end-to-end:
  - shell / unified-exec / apply_patch / managed-network / MCP guardian
  review
  - delegated/subagent approval routing into guardian review
  - guardian review risk metadata and action summaries for app-server/TUI
  - config/profile/TUI handling for `smart_approvals`, `guardian_approval`
  alias migration, and `approvals_reviewer`
  - a small internal cleanup of delegated approval forwarding to dedupe
  fallback paths and simplify guardian-vs-parent approval waiting (no
  intended behavior change)
  
  Out of scope for this PR:
  - redesigning the existing manual approval protocol shapes
  - persisting guardian review state onto app-server `ThreadItem`s
  - delegated MCP elicitation auto-review (the current delegated MCP
  guardian shim only covers the legacy `RequestUserInput` path)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-13 15:27:00 -07:00
  bc24017d64
• Override local apps settings with requirements.toml settings (#14304)

  This PR changes app and connector enablement when `requirements.toml` is
  present locally or via remote configuration.
  
  For apps.* entries:
  - `enabled = false` in `requirements.toml` overrides the user’s local
  `config.toml` and forces the app to be disabled.
  - `enabled = true` in `requirements.toml` does not re-enable an app the
  user has disabled in config.toml.
  
  This behavior applies whether or not the user has an explicit entry for
  that app in `config.toml`. It also applies to cloud-managed policies and
  configurations when the admin sets the override through
  `requirements.toml`.
  
  Scenarios tested and verified:
  - Remote managed, user config (present) override
  - Admin-defined policies & configurations include a connector override:
    `[apps.<appID>]
  enabled = false`
  - User's config.toml has the same connector configured with `enabled =
  true`
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
    
  - Remote managed, user config (absent) override
  - Admin-defined policies & configurations include a connector override:
    `[apps.<appID>]
  enabled = false`
    - User's config.toml has no entry for the the same connector
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
    
  - Locally managed, user config (present) override
    - Local requirements.toml includes a connector override:
    `[apps.<appID>]
  enabled = false`
  - User's config.toml has the same connector configured with `enabled =
  true`
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
  
  - Locally managed, user config (absent) override
    - Local requirements.toml includes a connector override:
    `[apps.<appID>]
  enabled = false`
    - User's config.toml has no entry for the the same connector
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
  
  
  
  
  <img width="1446" height="753" alt="image"
  src="https://github.com/user-attachments/assets/61c714ca-dcca-4952-8ad2-0afc16ff3835"
  />
  <img width="595" height="233" alt="image"
  src="https://github.com/user-attachments/assets/7c8ab147-8fd7-429a-89fb-591c21c15621"
  />

  canvrno-oai · 2026-03-13 12:40:24 -07:00
  914f7c7317
• Use subagents naming in the TUI (#14618)

  - rename user-facing TUI multi-agent wording to subagents
  - rename the surfaced slash command to `subagents` and update
  tests/snapshots
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-13 19:08:38 +00:00
  d58620c852
• feat: support skill-scoped managed network domain overrides in skill config (#14522)

  ## Summary
  
  This lets skill loading split `permissions.network` into two distinct
  pieces:
  
  - `permissions.network.enabled` still feeds the skill
  `PermissionProfile` and remains the coarse gate for whether the skill
  can use network access at all.
  - `permissions.network.allowed_domains` and
  `permissions.network.denied_domains` are lifted into a new
  `SkillManagedNetworkOverride` so managed-network sessions can start
  per-skill scoped proxies with the right domain overrides.
  
  The change also updates `SkillMetadata` construction sites and adds
  loader tests covering YAML parsing plus normalization of the network
  gate vs. domain override fields.
  
  ## Follow-up
  A PR that uses the network_override to spin up a skill-specific proxy if
  network_override is not none.

  Celia Chen · 2026-03-13 04:45:14 +00:00
  0c60eea4a5
• Include spawn agent model metadata in app-server items (#14410)

  - add model and reasoning effort to app-server collab spawn items and
  notifications
  - regenerate app-server protocol schemas for the new fields
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-11 19:25:21 -07:00
  bf5e997b31
• Show spawned agent model and effort in TUI (#14273)

  - include the requested sub-agent model and reasoning effort in the
  spawn begin event\n- render that metadata next to the spawned agent name
  and role in the TUI transcript
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-11 12:33:09 -07:00
  285b3a5143
• unifying all image saves to /tmp to bug-proof (#14149)

  image-gen feature will have the model saving to /tmp by default + at all
  times

  Won Park · 2026-03-11 12:33:08 -07:00
  722e8f08e1
• Use realtime transcript for handoff context (#14132)

  - collect input/output transcript deltas into active handoff transcript
  state
  - attach and clear that transcript on each handoff, and regenerate
  schema/tests

  Ahmed Ibrahim · 2026-03-09 22:30:03 -07:00
  2e24be2134
• [apps] Fix apps enablement condition. (#14011)

  - [x] Fix apps enablement condition to check both the feature flag and
  that the user is not an API key user.

  Matthew Zeng · 2026-03-09 22:25:43 -07:00
  566e4cee4b
• tui: only show fast status for gpt-5.4 (#14135)
  pash-openai · 2026-03-09 21:12:05 -07:00
  63597d1b2d
• start of hooks engine (#13276)

  (Experimental)
  
  This PR adds a first MVP for hooks, with SessionStart and Stop
  
  The core design is:
  
  - hooks live in a dedicated engine under codex-rs/hooks
  - each hook type has its own event-specific file
  - hook execution is synchronous and blocks normal turn progression while
  running
  - matching hooks run in parallel, then their results are aggregated into
  a normalized HookRunSummary
  
  On the AppServer side, hooks are exposed as operational metadata rather
  than transcript-native items:
  
  - new live notifications: hook/started, hook/completed
  - persisted/replayed hook results live on Turn.hookRuns
  - we intentionally did not add hook-specific ThreadItem variants
  
  Hooks messages are not persisted, they remain ephemeral. The context
  changes they add are (they get appended to the user's prompt)

  Andrei Eternal · 2026-03-10 04:11:31 +00:00
  244b2d53f4
• pass on save info to model + ui tweaks (#14123)

  Passing on more information to the model for context purposes, to
  streamline image-identification.

  Won Park · 2026-03-09 20:10:15 +00:00
  42f20a6845
• Stabilize guardian approval coverage (#14103)

  ## Summary
  - align the guardian permission test with the actual sandbox policy it
  widens and use a slightly larger Windows-only timeout budget
  - expose the additional-permissions normalization helper to the guardian
  test module
  - replace the guardian popup snapshot assertion with targeted string
  assertions
  
  ## Why this fixes the flake
  This group was carrying two separate sources of drift. The guardian core
  test widened derived sandbox policies without updating the source
  sandbox policy, and it used a Windows command/timeout combination that
  was too tight on slower runners. Separately, the TUI test was
  snapshotting the full popup even though unrelated feature text changes
  were the only thing moving. The new assertions keep coverage on the
  guardian entry itself while removing unrelated snapshot churn.

  Ahmed Ibrahim · 2026-03-09 11:23:20 -07:00
  e03e9b63ea
• guardian initial feedback / tweaks (#13897)

  ## Summary
  - remove the remaining model-visible guardian-specific `on-request`
  prompt additions so enabling the feature does not change the main
  approval-policy instructions
  - neutralize user-facing guardian wording to talk about automatic
  approval review / approval requests rather than a second reviewer or
  only sandbox escalations
  - tighten guardian retry-context handling so agent-authored
  `justification` stays in the structured action JSON and is not also
  injected as raw retry context
  - simplify guardian review plumbing in core by deleting dead
  prompt-append paths and trimming some request/transcript setup code
  
  ## Notable Changes
  - delete the dead `permissions/approval_policy/guardian.md` append path
  and stop threading `guardian_approval_enabled` through model-facing
  developer-instruction builders
  - rename the experimental feature copy to `Automatic approval review`
  and update the `/experimental` snapshot text accordingly
  - make approval-review status strings generic across shell, patch,
  network, and MCP review types
  - forward real sandbox/network retry reasons for shell and unified-exec
  guardian review, but do not pass agent-authored justification as raw
  retry context
  - simplify `guardian.rs` by removing the one-field request wrapper,
  deduping reasoning-effort selection, and cleaning up transcript entry
  collection
  
  ## Testing
  - `just fmt`
  - full validation left to CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-09 09:25:24 -07:00
  f23fcd6ced
• feat(tui) render request_permissions calls (#14004)

  ## Summary
  Adds support for tui rendering of request_permission calls
  
  <img width="724" height="245" alt="Screenshot 2026-03-08 at 9 04 07 PM"
  src="https://github.com/user-attachments/assets/e1997825-a496-4bfb-bbda-43d0006460a5"
  />
  
  
  ## Testing
  - [x] Added snapshot test

  Dylan Hurd · 2026-03-09 04:24:04 +00:00
  06f82c123c
• tui: clarify pending steer follow-ups (#13841)

  ## Summary
  - split the pending input preview into labeled pending-steer and queued
  follow-up sections
  - explain that pending steers submit after the next tool call and that
  Esc can interrupt and send them immediately
  - treat Esc as an interrupt-plus-resubmit path when pending steers
  exist, with updated TUI snapshots and tests
  
  Queues and steers:
  <img width="1038" height="263" alt="Screenshot 2026-03-07 at 10 17
  17 PM"
  src="https://github.com/user-attachments/assets/4ef433ef-27a3-4b7c-ad69-2046f6eb89e6"
  />
  
  After pressing Esc:
  <img width="1046" height="320" alt="Screenshot 2026-03-07 at 10 17
  21 PM"
  src="https://github.com/user-attachments/assets/0f4d89e0-b6b9-486a-9f04-b6021f169ba7"
  />
  
  ## Codex author
  `codex resume 019cc6f4-2cca-7803-b717-8264526dbd97`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-08 20:13:21 -07:00
  4ad3b59de3
• app-server: include experimental skill metadata in exec approval requests (#13929)

  ## Summary
  
  This change surfaces skill metadata on command approval requests so
  app-server clients can tell when an approval came from a skill script
  and identify the originating `SKILL.md`.
  
  - add `skill_metadata` to exec approval events in the shared protocol
  - thread skill metadata through core shell escalation and delegated
  approval handling for skill-triggered approvals
  - expose the field in app-server v2 as experimental `skillMetadata`
  - regenerate the JSON/TypeScript schemas and cover the new field in
  protocol, transport, core, and TUI tests
  
  ## Why
  
  Skill-triggered approvals already carry skill context inside core, but
  app-server clients could not see which skill caused the prompt. Sending
  the skill metadata with the approval request makes it possible for
  clients to present better approval UX and connect the prompt back to the
  relevant skill definition.
  
  
  ## example event in app-server-v2
  verified that we see this event when experimental api is on:
  ```
  < {
  <   "id": 11,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "additionalPermissions": {
  <       "fileSystem": null,
  <       "macos": {
  <         "accessibility": false,
  <         "automations": {
  <           "bundle_ids": [
  <             "com.apple.Notes"
  <           ]
  <         },
  <         "calendar": false,
  <         "preferences": "read_only"
  <       },
  <       "network": null
  <     },
  <     "approvalId": "25d600ee-5a3c-4746-8d17-e2e61fb4c563",
  <     "availableDecisions": [
  <       "accept",
  <       "acceptForSession",
  <       "cancel"
  <     ],
  <     "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <     "commandActions": [
  <       {
  <         "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes",
  <     "itemId": "call_jZp3xFpNg4D8iKAD49cvEvZy",
  <     "skillMetadata": {
  <       "pathToSkillsMd": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/SKILL.md"
  <     },
  <     "threadId": "019ccc10-b7d3-7ff2-84fe-3a75e7681e69",
  <     "turnId": "019ccc10-b848-76f1-81b3-4a1fa225493f"
  <   }
  < }`
  ```
  
  & verified that this is the event when experimental api is off:
  ```
  < {
  <   "id": 13,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "approvalId": "5fbbf776-261b-4cf8-899b-c125b547f2c0",
  <     "availableDecisions": [
  <       "accept",
  <       "acceptForSession",
  <       "cancel"
  <     ],
  <     "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <     "commandActions": [
  <       {
  <         "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Users/celia/code/codex/codex-rs",
  <     "itemId": "call_OV2DHzTgYcbYtWaTTBWlocOt",
  <     "threadId": "019ccc16-2a2b-7be1-8500-e00d45b892d4",
  <     "turnId": "019ccc16-2a8e-7961-98ec-649600e7d06a"
  <   }
  < }
  ```

  Celia Chen · 2026-03-08 18:07:46 -07:00
  340f9c9ecb
• chore: use @plugin instead of $plugin for plaintext mentions (#13921)

  change plaintext plugin-mentions from `$plugin` to `@plugin`, ensure TUI
  can correctly decode these from history.
  
  tested locally, added/updated tests.

  sayan-oai · 2026-03-08 01:36:39 +00:00
  590cfa6176
• Fix TUI context window display before first TokenCount (#13896)

  The TUI was showing the raw configured `model_context_window` until the
  first
  `TokenCount` event arrived, even though core had already emitted the
  effective
  runtime window on `TurnStarted`. This made the footer, status-line
  context
  window, and `/status` output briefly inconsistent for models/configs
  where the
  effective window differs from the configured value, such as the
  `gpt-5.4`
  1,000,000-token override reported in #13623.
  
  Update the TUI to cache `TurnStarted.model_context_window` immediately
  so
  pre-token-count displays use the runtime effective window, and add
  regression
  coverage for the startup path.
  
  ---------
  
  Co-authored-by: Charles Cunningham <ccunningham@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Eric Traut · 2026-03-07 17:01:47 -07:00
  e8d7ede83c
• fix(ci) fix guardian ci (#13911)

  ## Summary
  #13910 was merged with some unused imports, let's fix this
  
  ## Testing
  - [x] Let's make sure CI is green
  
  ---------
  
  Co-authored-by: Charles Cunningham <ccunningham@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-03-07 23:34:56 +00:00
  92f7541624
• Add guardian approval MVP (#13692)

  ## Summary
  - add the guardian reviewer flow for `on-request` approvals in command,
  patch, sandbox-retry, and managed-network approval paths
  - keep guardian behind `features.guardian_approval` instead of exposing
  a public `approval_policy = guardian` mode
  - route ordinary `OnRequest` approvals to the guardian subagent when the
  feature is enabled, without changing the public approval-mode surface
  
  ## Public model
  - public approval modes stay unchanged
  - guardian is enabled via `features.guardian_approval`
  - when that feature is on, `approval_policy = on-request` keeps the same
  approval boundaries but sends those approval requests to the guardian
  reviewer instead of the user
  - `/experimental` only persists the feature flag; it does not rewrite
  `approval_policy`
  - CLI and app-server no longer expose a separate `guardian` approval
  mode in this PR
  
  ## Guardian reviewer
  - the reviewer runs as a normal subagent and reuses the existing
  subagent/thread machinery
  - it is locked to a read-only sandbox and `approval_policy = never`
  - it does not inherit user/project exec-policy rules
  - it prefers `gpt-5.4` when the current provider exposes it, otherwise
  falls back to the parent turn's active model
  - it fail-closes on timeout, startup failure, malformed output, or any
  other review error
  - it currently auto-approves only when `risk_score < 80`
  
  ## Review context and policy
  - guardian mirrors `OnRequest` approval semantics rather than
  introducing a separate approval policy
  - explicit `require_escalated` requests follow the same approval surface
  as `OnRequest`; the difference is only who reviews them
  - managed-network allowlist misses that enter the approval flow are also
  reviewed by guardian
  - the review prompt includes bounded recent transcript history plus
  recent tool call/result evidence
  - transcript entries and planned-action strings are truncated with
  explicit `<guardian_truncated ... />` markers so large payloads stay
  bounded
  - apply-patch reviews include the full patch content (without
  duplicating the structured `changes` payload)
  - the guardian request layout is snapshot-tested using the same
  model-visible Responses request formatter used elsewhere in core
  
  ## Guardian network behavior
  - the guardian subagent inherits the parent session's managed-network
  allowlist when one exists, so it can use the same approved network
  surface while reviewing
  - exact session-scoped network approvals are copied into the guardian
  session with protocol/port scope preserved
  - those copied approvals are now seeded before the guardian's first turn
  is submitted, so inherited approvals are available during any immediate
  review-time checks
  
  ## Out of scope / follow-ups
  - the sandbox-permission validation split was pulled into a separate PR
  and is not part of this diff
  - a future follow-up can enable `serde_json` preserve-order in
  `codex-core` and then simplify the guardian action rendering further
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-07 05:40:10 -08:00
  e84ee33cc0
• Add Fast mode status-line indicator (#13670)

  Addresses feature request #13660
  
  Adds new option to `/statusline` so the status line can display "fast
  on" or "fast off"
  
  Summary
  - introduce a `FastMode` status-line item so `/statusline` can render
  explicit `Fast on`/`Fast off` text for the service tier
  - wire the item into the picker metadata and resolve its string from
  `ChatWidget` without adding any unrelated `thread-name` logic or storage
  changes
  - ensure the refresh paths keep the cached footer in sync when the
  service tier (fast mode) changes
  
  Testing
  - Manually tested
  
  Here's what it looks like when enabled:
  
  <img width="366" height="75" alt="image"
  src="https://github.com/user-attachments/assets/7f992d2b-6dab-49ed-aa43-ad496f56f193"
  />

  Eric Traut · 2026-03-07 00:42:08 -07:00
  8df4d9b3b2
• chore(otel): rename OtelManager to SessionTelemetry (#13808)

  ## Summary
  This is a purely mechanical refactor of `OtelManager` ->
  `SessionTelemetry` to better convey what the struct is doing. No
  behavior change.
  
  ## Why
  
  `OtelManager` ended up sounding much broader than what this type
  actually does. It doesn't manage OTEL globally; it's the session-scoped
  telemetry surface for emitting log/trace events and recording metrics
  with consistent session metadata (`app_version`, `model`, `slug`,
  `originator`, etc.).
  
  `SessionTelemetry` is a more accurate name, and updating the call sites
  makes that boundary a lot easier to follow.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-otel`
  - `cargo test -p codex-core`

  Owen Lin · 2026-03-06 16:23:30 -08:00
  289ed549cf
• feat: structured plugin parsing (#13711)

  #### What
  
  Add structured `@plugin` parsing and TUI support for plugin mentions.
  
  - Core: switch from plain-text `@display_name` parsing to structured
  `plugin://...` mentions via `UserInput::Mention` and
  `[$...](plugin://...)` links in text, same pattern as apps/skills.
  - TUI: add plugin mention popup, autocomplete, and chips when typing
  `$`. Load plugin capability summaries and feed them into the composer;
  plugin mentions appear alongside skills and apps.
  - Generalize mention parsing to a sigil parameter, still defaults to `$`
  
  <img width="797" height="119" alt="image"
  src="https://github.com/user-attachments/assets/f0fe2658-d908-4927-9139-73f850805ceb"
  />
  
  Builds on #13510. Currently clients have to build their own `id` via
  `plugin@marketplace` and filter plugins to show by `enabled`, but we
  will add `id` and `available` as fields returned from `plugin/list`
  soon.
  
  ####Tests
  
  Added tests, verified locally.

  sayan-oai · 2026-03-06 11:08:36 -08:00
  8a54d3caaa
• Enabling CWD Saving for Image-Gen (#13607)

  Codex now saves the generated image on to your current working
  directory.

  Won Park · 2026-03-06 00:47:21 -08:00
  ee1a20258a
• Update models.json (#13617)

  - Update `models.json` to surface the new model entry.
  - Refresh the TUI model picker snapshot to match the updated catalog
  ordering.
  
  ---------
  
  Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>

  Ahmed Ibrahim · 2026-03-05 16:22:39 -08:00
  3ff618b493
• add @plugin mentions (#13510)

  ## Note-- added plugin mentions via @, but that conflicts with file
  mentions
  
  depends and builds upon #13433.
  
  - introduces explicit `@plugin` mentions. this injects the plugin's mcp
  servers, app names, and skill name format into turn context as a dev
  message.
  - we do not yet have UI for these mentions, so we currently parse raw
  text (as opposed to skills and apps which have UI chips, autocomplete,
  etc.) this depends on a `plugins/list` app-server endpoint we can feed
  the UI with, which is upcoming
  - also annotate mcp and app tool descriptions with the plugin(s) they
  come from. this gives the model a first class way of understanding what
  tools come from which plugins, which will help implicit invocation.
  
  ### Tests
  Added and updated tests, unit and integration. Also confirmed locally a
  raw `@plugin` injects the dev message, and the model knows about its
  apps, mcps, and skills.

  sayan-oai · 2026-03-06 00:03:39 +00:00
  4e77ea0ec7
• [diagnostics] show diagnostics earlier in workflow (#13604)

  <img width="591" height="243" alt="Screenshot 2026-03-05 at 10 17 06 AM"
  src="https://github.com/user-attachments/assets/84a6658b-6017-4602-b1f8-2098b9b5eff9"
  />
  
  - show feedback earlier
  - preserve raw literal env vars (no trimming, sanitizing, etc.)

  rhan-oai · 2026-03-05 11:23:47 -08:00
  9fcbbeb5ae
• [tui] Show speed in session header (#13446)

  - add a speed row to the startup/session header under the model row
  - render the speed row with the same styling pattern as the model row,
  using /fast to change
  - show only Fast or Standard to users and update the affected snapshots
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pash-openai · 2026-03-05 00:00:16 -08:00
  1ce1712aeb
• image-gen-event/client_processing (#13512)

  enabling client-side to process with image-generation capabilities
  (setting app-server)

  Won Park · 2026-03-04 16:54:38 -08:00
  229e6d0347
• Notify TUI about plan mode prompts and user input requests (#13495)

  Addresses #13478
  
  Summary
  - Add two new scopes for `tui.notifications` config: `plan-mode-prompt`
  and `user-input-requested`.
  - Add Plan Mode prompt and user-input-requested notifications to the TUI
  so these events surface consistently outside of plan mode
  - Add helpers and tests to ensure the new notification types publish the
  right titles, summaries, and type tags for filtering
  - Add prioritization mechanism to fix an existing bug where one
  notification event could arbitrarily overwrite others
  
  Testing
  - Manually tested plan mode to ensure that notification appeared

  Eric Traut · 2026-03-04 15:08:57 -07:00
  f80e5d979d
• fix: bad merge (#13461)
  jif-oai · 2026-03-04 11:00:48 +00:00
  e6b2e3a9f7
• fix: pending messages in /agent (#13240)
  jif-oai · 2026-03-04 10:17:29 +00:00
  e4a202ea52
• config: enforce enterprise feature requirements (#13388)

  ## Why
  
  Enterprises can already constrain approvals, sandboxing, and web search
  through `requirements.toml` and MDM, but feature flags were still only
  configurable as managed defaults. That meant an enterprise could suggest
  feature values, but it could not actually pin them.
  
  This change closes that gap and makes enterprise feature requirements
  behave like the other constrained settings. The effective feature set
  now stays consistent with enterprise requirements during config load,
  when config writes are validated, and when runtime code mutates feature
  flags later in the session.
  
  It also tightens the runtime API for managed features. `ManagedFeatures`
  now follows the same constraint-oriented shape as `Constrained<T>`
  instead of exposing panic-prone mutation helpers, and production code
  can no longer construct it through an unconstrained `From<Features>`
  path.
  
  The PR also hardens the `compact_resume_fork` integration coverage on
  Windows. After the feature-management changes,
  `compact_resume_after_second_compaction_preserves_history` was
  overflowing the libtest/Tokio thread stacks on Windows, so the test now
  uses an explicit larger-stack harness as a pragmatic mitigation. That
  may not be the ideal root-cause fix, and it merits a parallel
  investigation into whether part of the async future chain should be
  boxed to reduce stack pressure instead.
  
  ## What Changed
  
  Enterprises can now pin feature values in `requirements.toml` with the
  requirements-side `features` table:
  
  ```toml
  [features]
  personality = true
  unified_exec = false
  ```
  
  Only canonical feature keys are allowed in the requirements `features`
  table; omitted keys remain unconstrained.
  
  - Added a requirements-side pinned feature map to
  `ConfigRequirementsToml`, threaded it through source-preserving
  requirements merge and normalization in `codex-config`, and made the
  TOML surface use `[features]` (while still accepting legacy
  `[feature_requirements]` for compatibility).
  - Exposed `featureRequirements` from `configRequirements/read`,
  regenerated the JSON/TypeScript schema artifacts, and updated the
  app-server README.
  - Wrapped the effective feature set in `ManagedFeatures`, backed by
  `ConstrainedWithSource<Features>`, and changed its API to mirror
  `Constrained<T>`: `can_set(...)`, `set(...) -> ConstraintResult<()>`,
  and result-returning `enable` / `disable` / `set_enabled` helpers.
  - Removed the legacy-usage and bulk-map passthroughs from
  `ManagedFeatures`; callers that need those behaviors now mutate a plain
  `Features` value and reapply it through `set(...)`, so the constrained
  wrapper remains the enforcement boundary.
  - Removed the production loophole for constructing unconstrained
  `ManagedFeatures`. Non-test code now creates it through the configured
  feature-loading path, and `impl From<Features> for ManagedFeatures` is
  restricted to `#[cfg(test)]`.
  - Rejected legacy feature aliases in enterprise feature requirements,
  and return a load error when a pinned combination cannot survive
  dependency normalization.
  - Validated config writes against enterprise feature requirements before
  persisting changes, including explicit conflicting writes and
  profile-specific feature states that normalize into invalid
  combinations.
  - Updated runtime and TUI feature-toggle paths to use the constrained
  setter API and to persist or apply the effective post-constraint value
  rather than the requested value.
  - Updated the `core_test_support` Bazel target to include the bundled
  core model-catalog fixtures in its runtime data, so helper code that
  resolves `core/models.json` through runfiles works in remote Bazel test
  environments.
  - Renamed the core config test coverage to emphasize that effective
  feature values are normalized at runtime, while conflicting persisted
  config writes are rejected.
  - Ran `compact_resume_after_second_compaction_preserves_history` inside
  an explicit 8 MiB test thread and Tokio runtime worker stack, following
  the existing larger-stack integration-test pattern, to keep the Windows
  `compact_resume_fork` test slice from aborting while a parallel
  investigation continues into whether some of the underlying async
  futures should be boxed.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core feature_requirements_ -- --nocapture`
  - `cargo test -p codex-core
  load_requirements_toml_produces_expected_constraints -- --nocapture`
  - `cargo test -p codex-core
  compact_resume_after_second_compaction_preserves_history -- --nocapture`
  - `cargo test -p codex-core compact_resume_fork -- --nocapture`
  - Re-ran the built `codex-core` `tests/all` binary with
  `RUST_MIN_STACK=262144` for
  `compact_resume_after_second_compaction_preserves_history` to confirm
  the explicit-stack harness fixes the deterministic low-stack repro.
  - `cargo test -p codex-core`
  - This still fails locally in unrelated integration areas that expect
  the `codex` / `test_stdio_server` binaries or hit existing `search_tool`
  wiremock mismatches.
  
  ## Docs
  
  `developers.openai.com/codex` should document the requirements-side
  `[features]` table for enterprise and MDM-managed configuration,
  including that it only accepts canonical feature keys and that
  conflicting config writes are rejected.

  Michael Bolin · 2026-03-04 04:40:22 +00:00
  bfff0c729f
• [feedback] diagnostics (#13292)

  - added header logic to display diagnostics on cli
  - added logic for collecting env vars
  
  <img width="606" height="327" alt="Screenshot 2026-03-03 at 3 49 31 PM"
  src="https://github.com/user-attachments/assets/05e78c56-8cb3-47fa-abaf-3e57f1fdd8e2"
  />
  
  <img width="690" height="353" alt="Screenshot 2026-03-02 at 6 47 54 PM"
  src="https://github.com/user-attachments/assets/e470b559-13f4-44d9-897f-bc398943c6d1"
  />

  rhan-oai · 2026-03-03 16:34:11 -08:00
  e951ef4374
• tui: align pending steers with core acceptance (#12868)

  ## Summary
  - submit `Enter` steers immediately while a turn is already running
  instead of routing them through `queued_user_messages`
  - keep those submitted steers visible in the footer as `pending_steers`
  until core records them as a user message or aborts the turn
  - reconcile pending steers on `ItemCompleted(UserMessage)`, not
  `RawResponseItem`
  - emit user-message item lifecycle for leftover pending input at task
  finish, then remove the TUI `TurnComplete` fallback
  - keep `queued_user_messages` for actual queued drafts, rendered below
  pending steers
  
  ## Problem
  While the assistant was generating, pressing `Enter` could send the
  input into `queued_user_messages`. That queue only drains after the turn
  ends, so ordinary steers behaved like queued drafts instead of landing
  at the next core sampling boundary.
  
  The first version of this fix also used `RawResponseItem` to decide when
  a steer had landed. Review feedback was that this is the wrong
  abstraction for client behavior.
  
  There was also a late edge case in core: if pending steer input was
  accepted after the final sampling decision but before `TurnComplete`,
  core would record that user message into history at task finish without
  emitting `ItemStarted(UserMessage)` / `ItemCompleted(UserMessage)`. TUI
  had a fallback to paper over that gap locally.
  
  ## Approach
  - `Enter` during an active turn now submits a normal `Op::UserTurn`
  immediately
  - TUI keeps a local pending-steer preview instead of rendering that user
  message into history immediately
  - when core records the steer as `ItemCompleted(UserMessage)`, TUI
  matches and removes the corresponding pending preview, then renders the
  committed user message
  - core now emits the same user-message lifecycle when
  `on_task_finished(...)` drains leftover pending user input, before
  `TurnComplete`
  - with that lifecycle gap closed in core, TUI no longer needs to flush
  pending steers into history on `TurnComplete`
  - if the turn is interrupted, pending steers and queued drafts are both
  restored into the composer, with pending steers first
  
  ## Notes
  - `Tab` still uses the real queued-message path
  - `queued_user_messages` and `pending_steers` are separate state with
  separate semantics
  - the pending-steer matching key is built directly from `UserInput`
  - this removes the new TUI dependency on `RawResponseItem`
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-core
  task_finish_emits_turn_item_lifecycle_for_leftover_pending_user_input --
  --nocapture`
  - `cargo test -p codex-tui`

  Charley Cunningham · 2026-03-03 15:31:52 -08:00
  299b8ac445
• app-server service tier plumbing (plus some cleanup) (#13334)

  followup to https://github.com/openai/codex/pull/13212 to expose fast
  tier controls to app server
  (majority of this PR is generated schema jsons - actual code is +69 /
  -35 and +24 tests )
  
  - add service tier fields to the app-server protocol surfaces used by
  thread lifecycle, turn start, config, and session configured events
  - thread service tier through the app-server message processor and core
  thread config snapshots
  - allow runtime config overrides to carry service tier for app-server
  callers
  
  cleanup:
  - Removing useless "legacy" code supporting "standard" - we moved to
  None | "fast", so "standard" is not needed.

  pash-openai · 2026-03-03 02:35:09 -08:00
  07e532dcb9
• add fast mode toggle (#13212)

  - add a local Fast mode setting in codex-core (similar to how model id
  is currently stored on disk locally)
  - send `service_tier=priority` on requests when Fast is enabled
  - add `/fast` in the TUI and persist it locally
  - feature flag

  pash-openai · 2026-03-02 20:29:33 -08:00
  2f5b01abd6
• chore: remove SkillMetadata.permissions and derive skill sandboxing from permission_profile (#13061)

  ## Summary
  
  This change removes the compiled permissions field from skill metadata
  and keeps permission_profile as the single source of truth.
  
  Skill loading no longer compiles skill permissions eagerly. Instead, the
  zsh-fork skill escalation path compiles `skill.permission_profile` when
  it needs to determine the sandbox to apply for a skill script.
  
    ## Behavior change
  
    For skills that declare:
  ```
    permissions: {}
  ```
  we now treat that the same as having no skill permissions override,
  instead of creating and using a default readonly sandbox. This change
  makes the behavior more intuitive:
  
    - only non-empty skill permission profiles affect sandboxing
  - omitting permissions and writing permissions: {} now mean the same
  thing
  - skill metadata keeps a single permissions representation instead of
  storing derived state too
  
  Overall, this makes skill sandbox behavior easier to understand and more
  predictable.

  Celia Chen · 2026-03-03 01:29:53 +00:00
  0bb152b01d
• Update realtime websocket API (#13265)

  - migrate the realtime websocket transport to the new session and
  handoff flow
  - make the realtime model configurable in config.toml and use API-key
  auth for the websocket
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-02 16:05:40 -08:00
  b20b6aa46f
• feat: enable ma through /agent (#13246)

  <img width="639" height="139" alt="Screenshot 2026-03-02 at 16 06 41"
  src="https://github.com/user-attachments/assets/c006fcec-c1e7-41ce-bb84-c121d5ffb501"
  />
  
  Then
  <img width="372" height="37" alt="Screenshot 2026-03-02 at 16 06 49"
  src="https://github.com/user-attachments/assets/aa4ad703-e7e7-4620-9032-f5cd4f48ff79"
  />

  jif-oai · 2026-03-02 18:37:29 +00:00
  f8838fd6f3
• feat: approval for sub-agent in the TUI (#12995)

  <img width="766" height="290" alt="Screenshot 2026-02-27 at 10 50 48"
  src="https://github.com/user-attachments/assets/3bc96cd9-ed2c-4d67-a317-8f7b60abbbb1"
  />

  jif-oai · 2026-02-28 14:07:07 +01:00
  2b38b4e03b
• Add model availability NUX tooltips (#13021)

  - override startup tooltips with model availability NUX and persist
  per-model show counts in config
  - stop showing each model after four exposures and fall back to normal
  tooltips

  Ahmed Ibrahim · 2026-02-27 17:14:06 -08:00
  ec6f6aacbf
• notify: include client in legacy hook payload (#12968)

  ## Why
  
  The `notify` hook payload did not identify which Codex client started
  the turn. That meant downstream notification hooks could not distinguish
  between completions coming from the TUI and completions coming from
  app-server clients such as VS Code or Xcode. Now that the Codex App
  provides its own desktop notifications, it would be nice to be able to
  filter those out.
  
  This change adds that context without changing the existing payload
  shape for callers that do not know the client name, and keeps the new
  end-to-end test cross-platform.
  
  ## What changed
  
  - added an optional top-level `client` field to the legacy `notify` JSON
  payload
  - threaded that value through `core` and `hooks`; the internal session
  and turn state now carries it as `app_server_client_name`
  - set the field to `codex-tui` for TUI turns
  - captured `initialize.clientInfo.name` in the app server and applied it
  to subsequent turns before dispatching hooks
  - replaced the notify integration test hook with a `python3` script so
  the test does not rely on Unix shell permissions or `bash`
  - documented the new field in `docs/config.md`
  
  ## Testing
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-app-server
  suite::v2::initialize::turn_start_notify_payload_includes_initialize_client_name
  -- --exact --nocapture`
  - `cargo test -p codex-core` (`src/lib.rs` passed; `core/tests/all.rs`
  still has unrelated existing failures in this environment)
  
  ## Docs
  
  The public config reference on `developers.openai.com/codex` should
  mention that the legacy `notify` payload may include a top-level
  `client` field. The TUI reports `codex-tui`, and the app server reports
  `initialize.clientInfo.name` when it is available.

  Michael Bolin · 2026-02-26 22:27:34 -08:00
  e6cd75a684