## Why
Client-supplied tool outputs can carry task instructions. Even when marked with `retain: true`, these instructions could be trimmed before compaction and disappear from the compacted history.
## What changed
Add the disabled-by-default `retain_client_tool_outputs` feature to honor retention for explicitly marked, named `function_call_output` items without a `call_id`.
- Preserve eligible outputs in remote compaction v2 and when starting a new context window, keeping their original role.
- Stop emergency tool-output trimming at a retained output.
- Share the existing 64,000-token retention budget, keeping outputs whole and dropping an oversized output and older items rather than partially truncating it.
- Place initial context before retained standalone outputs and account for their images in retained-image counts.
## Testing
Add a scenario covering enabled and disabled retention, emergency trimming, oversized-output handling, and preservation of the latest instruction after compaction and cold resume. Verify that retention annotations stay out of model requests.
GitOrigin-RevId: 449179670e4d2be2623928700738758e43b5dc1a
## What changed
Add an optional `retain` flag to `TurnToolOutput` for `turn/start`. When set to `true`, pass the output to the core with a retention annotation to request retention in the thread's model history. The flag defaults to `false`, preserving existing behavior.
Update the generated JSON schemas, TypeScript types, and Python bindings to expose the flag.
## Testing
Add an integration test verifying that a retained tool output reaches the model and preserves client-authored sender metadata in persisted history, including the receiver message ID.
GitOrigin-RevId: 52893a8fcb308f26e77ba8f0bee9990073b26d54
## What changed
Add `TurnInput::AnnotatedResponseItem` with a caller-supplied `retain` annotation. For function-call outputs, `retain: true` sets `client_authored` history metadata while keeping annotations out of model requests. Accept annotated items through the existing turn submission paths, including continuation.
## Testing
Add an integration test covering retention metadata during turn start, steering, idle submission, and rollout storage. Verify that ordinary outputs remain unmarked and model requests contain neither `retain` nor `client_authored`.
GitOrigin-RevId: 7285dde31149b17b0dcf31d4ea1c7cba66d9efe6
## What changed
Mark `code_mode_interrupt` as stable and enable it by default, so interrupting a turn terminates active code mode cells and nested tool calls.
## Testing
Update the existing interruption test to use the feature default instead of explicitly enabling `CodeModeInterrupt`. It verifies that active cells and nested tools are aborted while stored session values remain available.
GitOrigin-RevId: 17be94f208713bc232e2292feb48261938254db3
## Why
Environment readiness previously changed which tools and command parameters were advertised to the model, even when the selected environments stayed the same.
## What changed
- Keep enabled command, patch, image, and permission tools exposed when environments are absent, starting, or failed.
- Return a consistent message asking the model to wait when no usable execution environment is available, while preserving distinct errors for unknown environment IDs.
- Derive environment selectors from all selected environments rather than only ready ones.
- Always advertise `exec_command`'s `shell` and `login` parameters while continuing to enforce login policy at execution time.
## Testing
Expand integration coverage for empty, pending, failed, ready, and recovered environments, including stable command parameters and login-policy rejection. Update subagent and skill-catalog snapshots, with separate Windows expectations.
GitOrigin-RevId: bb08084066896a9f14b3b568c081c3eaac981db7
## What changed
Move content-filter guidance recording from the sampling loop into
`handle_response_stream_error`. Pass `StepContext` so the handler can resolve
model-specific guidance and record it before retry decisions for sampling
requests. Keep remote compaction excluded from guidance recording and update
callers and the existing retry-deadline test to use the new signature.
GitOrigin-RevId: 030bde1d4f1597fc4f3971ad837478e5304c5aa9
## Why
Responses stopped by `content_filter` previously followed generic stream-error retry handling without guidance about the block. Retried requests need instructions to explain the limitation and offer a permitted alternative.
## What changed
- Recognize content-filter failures as a distinct error while preserving retryability and the existing public error representation.
- Append developer guidance to the conversation after each sampling block, retaining delivered output and using the existing retry handling.
- Support a model catalog override through `model_messages.content_filter_guidance`. Missing, null, blank, or values exceeding 512 UTF-8 bytes fall back to bundled guidance.
- The bundled guidance tells the model to avoid reproducing or working around blocked content, briefly explain the limitation, offer a permitted alternative, and continue unrelated authorized work.
## Testing
Add a scenario and request-history snapshot covering repeated blocks, catalog guidance on each retry, retained partial output, and eventual completion. Add error-mapping assertions for retryability, public error classification, and error text.
GitOrigin-RevId: ba0c201b3a5a3acf5cfa971332027240e0690225
## Why
Guardian denial-limit interruptions lack a structured error identifying the cause. Make this opt-in because older clients may not recognize the new error in shared history.
## What changed
- Add `auto_review.circuit_break_action = "strict"` to attach `TooManyDenials` to the interrupted turn. The default leaves the error unset.
- Expose `turn.error.codexErrorInfo = "tooManyDenials"` in app-server notifications and saved history, and update protocol schemas and generated types.
- Preserve the warning, denial limit, and interrupted status without emitting a separate error notification.
## Testing
Add an integration test covering omitted, `default`, and `strict` settings, checking warnings, live turn errors, the absence of separate error notifications, and persisted turn errors after restart.
GitOrigin-RevId: cb5d379e64728d4d7b9daf834c13756e4a70db31
## What changed
- Add `auto_review.extra_policy` and the managed `guardian_extra_policy` requirement to supply policy text alongside the resolved tenant policy. Nonblank managed values take precedence; blank values are ignored.
- Render the additional text through `{{ extra_policy }}` in Guardian reviewer templates and append it to the tenant policy for Guardian v2 classification before truncation.
- Preserve placeholder-like text inside supplied policies literally.
## Testing
Add coverage for configuration precedence, blank values, template substitution, and classifier prompts, plus a scenario verifying that managed tenant and extra policies reach the Guardian reviewer together.
GitOrigin-RevId: 180d8d716c63fe96a92ec5bfbd22db4ddccd4f1f
## Why
Older Desktop clients can still provide bundled Sites to an independently updated SSH app-server. A cached remote Sites install must take precedence, even when disabled, while a missing remote bundle must preserve the bundled fallback.
## What changed
- Remove persisted bundled-plugin exclusions, Sites migration checks, and the migration wait when loading local plugin configuration.
- Suppress `sites@openai-bundled` during plugin loading when the remote global catalog is active and a cached remote Sites install is available.
- Remove exclusion-based catalog filtering and read/install guards, and simplify `install_plugin` to accept `ConfigLayerStack`.
## Testing
Expand the agent-turn Sites test to cover enabled remote precedence, disabled remote suppression of bundled Sites, and fallback when the remote bundle is missing.
GitOrigin-RevId: e2758596e5493ccee051cdfbf6b4afbe4f98948c
## What changed
Add `auto_review.experimental_policy_template` to override the Guardian prompt template in `config.toml`. Trim the configured value and ignore it when empty. Prefer the override over the model catalog template, retaining the bundled template as the final fallback.
The template's `{{ tenant_policy_config }}` placeholder is replaced with the resolved Guardian policy.
## Testing
Extend tests to cover template deserialization, trimming, precedence over the catalog template, and rendered policy text in Guardian inference requests.
GitOrigin-RevId: 85b4a8fc193a42735354894203ccbd1f738a3b58
## Why
Serialized response items include message IDs, metadata, and JSON escaping that inflate token estimates without adding model-visible content.
## What changed
- Estimate each response item from its content, retaining JSON syntax for structured tool payloads.
- Apply image estimates to all image inputs, including non-base64 URLs, and count audio and encrypted content through their modality-specific estimates.
- Exclude plaintext reasoning and bookkeeping-only items from replay accounting.
## Testing
Update unit expectations for text, images, audio, and encrypted content. Add a remote compaction regression test showing that equal-length text produces identical token usage estimates despite different message IDs, metadata, and JSON escaping, while preserving the submitted messages.
GitOrigin-RevId: 1c43d5abbcc1668b4ab413901a2b4b6511ca5892
## What changed
Increase `GUARDIAN_MAX_ACTION_BYTES` from 8,000 to 200,000 bytes to allow larger actions to be reviewed. Keep unified exec stdin approvals capped at 8,000 bytes with a separate `MAX_STDIN_APPROVAL_BYTES` constant.
## Testing
Update aggregate payload rejection coverage for the new limit and exercise MCP elicitation reviews with tool descriptions exceeding the previous 8,000-byte limit.
GitOrigin-RevId: fd4b97980803a7a687449043931e6f1e57e260d3
## Why
Guardian reviewers can inherit token-budget mode from the parent session or model defaults, causing context rollover instead of summary-based compaction.
## What changed
Clear inherited token-budget startup activation, set an explicit default `TokenBudgetConfig`, and disable `Feature::TokenBudget` and `Feature::ContextManagement` for Guardian review sessions.
## Testing
Update regression coverage to verify that reviewers compact with a summary even when the parent and model enable token budgets. Cover both transcript modes and browser evidence, checking that review requests omit `token_budget.context_window` and retain the compaction summary.
GitOrigin-RevId: e1a84f9c7752a712399cd749c3834b2a7bb4a7e6
## Why
Sandboxed commands inherit the user's controlling terminal. Without an explicit
restriction, a child can use `TIOCSTI` to queue input for the unsandboxed shell
that resumes after Codex exits.
## What changed
Append a `file-ioctl` denial for `TIOCSTI` after the shared Seatbelt policy
allowances used by `codex sandbox`.
## Testing
Add a macOS PTY integration test that first proves terminal input injection
works without the sandbox, then verifies Seatbelt rejects it with `EPERM`.
GitOrigin-RevId: 5a8b0a5b4fd980cc406ad184d04ceae9b0ea90e4
## Why
When the remote Sites plugin is installed and its local bundle is available, exposing the bundled copy as well creates duplicate catalog entries and can load the wrong skills.
## What changed
- Persist an account- and backend-scoped exclusion for `sites@openai-bundled` once the remote replacement is installed and loadable.
- Apply the exclusion to plugin catalogs, search, direct reads and installs, runtime loading, hooks, and skill caches while preserving the remote plugin's server-owned enabled state.
- Restore the bundled fallback when the remote plugin is absent or its local files are unavailable, and throttle repeated availability checks for 60 seconds.
## Testing
- Added manager tests for persistence across restarts, account/backend isolation, fallback restoration, concurrent checks, and refresh throttling.
- Added app-server and agent-turn tests confirming that catalog, search, and skill loading prefer remote Sites.
GitOrigin-RevId: bc1154f79d3107910fee9fa27389a0ddb48ce6cf
## Why
Cloud task requests can use saved ChatGPT credentials, so their destination must be constrained before authentication is loaded or any request is made.
## What changed
- Validate `CODEX_CLOUD_TASKS_BASE_URL` against trusted ChatGPT HTTPS origins on port 443 and reject URLs containing user information, queries, or fragments.
- Disable redirects for cloud task backend and environment-discovery clients so credentials are never forwarded to a redirect destination.
- Normalize the validated base URL before configuring authentication and HTTP clients.
## Testing
Add a CLI integration test that verifies a custom cloud backend is rejected without receiving a request, while the staging origin continues to use explicit token authentication.
GitOrigin-RevId: f0dddf363b4e44ea3530f81d9a817e978c15ead2
## What changed
- Add a synchronous reviewer prompt builder that combines root authorization,
trusted user answers, bounded conversation history, parent environment and
permission context, retained REPL evidence, and the proposed action.
- Select text or image REPL evidence from Guardian feature and transcript
settings while respecting the reviewer model's supported modalities and
shared image limits.
- Render network access requests with trigger-specific guidance and bound
approval reasons and nested action strings before including them.
## Testing
- Add a prompt test covering root authorization, untrusted transcript framing,
retry reasons, denied-read restrictions, and action serialization.
GitOrigin-RevId: d1cf886c2e30f7abbf94cce977cef14439ef3f2e
## What changed
- Add a policy prompt and output contract for synchronous Guardian reviews.
- Build reviewer thread options with a preferred review model, low reasoning effort when supported, and a fallback to the parent model and effective effort.
- Isolate reviewer sessions from parent instructions, MCP servers, optional features, and write access while preserving read restrictions, resolved environments, managed network constraints, and rollout persistence.
- Mark prepared threads as internal Guardian review sessions for later host-managed startup.
## Testing
- Cover reviewer isolation, read-only environment inheritance, review-model overrides, and parent-model fallback behavior.
GitOrigin-RevId: 5133be99674b64e06e19e7f2dbc86439e1678790
## Why
Guardian sessions can run alongside another Windows sandbox launch and should not reconcile the persistent proxy settings established by that launch.
## What changed
- Start internal Guardian sessions with `WindowsSandboxProxySettingsMode::Preserve`.
- Continue using `Reconcile` for other sessions.
## Testing
Added a thread manager test that verifies a parent session reconciles proxy settings while its internal Guardian session preserves them.
GitOrigin-RevId: c6a31637ecdf828548cfd7153da7e9405abe34fa
## Why
Internal Guardian reviews must remain independent of parent-session customization while still honoring managed execution and environment restrictions.
## What changed
- Apply the restricted Guardian session path to both internal and subagent review sources.
- Start internal reviews without inherited user instructions, extensions, MCP servers, or multi-agent behavior.
- Preserve managed execution policy and selected environment constraints while exposing only the allowed review tools. Honor shell feature restrictions across every selected environment and retain code mode when enabled.
## Testing
- Cover internal review isolation from parent state and managed instructions.
- Cover optional tool filtering, managed shell restrictions, code mode, and secondary environment profiles.
GitOrigin-RevId: edbf7d8a6fe3ee8213a1c75bc8ec331a1cf49006
## What changed
- Split the approval review contributor into a `fast_decision` path for existing evidence and a `full_review` path for structured reviews.
- Add host-owned full-review inputs with action evidence, conversation history, thread and turn identifiers, approval context, and extension data.
- Add structured assessment and error types, and resolve full reviews using the first contributor that claims the request.
## Testing
- Cover full-review input propagation, first-claim ordering, and short-circuit behavior in the extension registry tests.
GitOrigin-RevId: 6f763d874af8c0b66a0d760b7b7c7dfe32251c9e
## What changed
Propagate tool cancellation tokens into Guardian approval reviews so interrupting a tool also aborts its pending review. Apply the same cancellation behavior to server-initiated MCP approval elicitation.
## Testing
Add integration coverage for cancellation from direct tool calls, code-mode turns, background code-mode cells, and MCP elicitation.
GitOrigin-RevId: cbee4b422bbcbf6984e415ef6409cee705beebdc
## What changed
- Add an extension API for spawning host-owned internal sessions and a
`ThreadReadyInput` lifecycle callback that runs after thread registration.
- Add Guardian reviewer session scaffolding that records the parent thread and
effective model, plus the under-development `guardian_ext` feature flag.
- Start internal sessions with fresh history while preserving parent lineage,
shared session controls, and internal-thread visibility rules.
- Scope internal-session prompt cache keys to their source and parent thread,
and expose `guardian` as an internal session source.
## Testing
- Cover internal-session spawning, parent metadata, history isolation, prompt
cache keys, and extension spawner argument forwarding.
GitOrigin-RevId: 682dae80397d62bb36247796b447042e760ca364
## What changed
- Add the under-development `guardian_reuse_parent_compaction` feature.
- Restart Guardian review sessions after parent history rewrites and seed them with the latest encrypted compaction that has a response item ID.
- Keep the existing reviewer when a rewritten history has no reusable compaction, preserving authorization and restriction context held by that session.
## Testing
- Cover reuse-key invalidation and compaction eligibility.
- Verify review-session behavior across parent compaction and a subsequent summary-free history reset.
GitOrigin-RevId: 891805d3c3dca34ddda6e3bfc5097be4ff164267
## What changed
- Propagate the optional `modelSpecialty` field through the model catalog and
app-server `model/list` response.
- When a newly selected model has the `cyber` specialty, default an active TUI
thread to workspace-write permissions with on-request approval. Use auto
review when available, otherwise keep the user as reviewer, while respecting
configured permission requirements.
- Show a notice when auto review is applied and strengthen the full-access
warning for cyber models.
- Preserve explicitly selected permissions when only reasoning settings change.
## Testing
- Cover auto-review defaults, requirement-aware fallback behavior, permission
preservation across reasoning changes, and the new warning notice.
GitOrigin-RevId: 8f25b0082d3051d9ff91f7355921236d0f82f758
## What changed
- Add `GuardianV2` to the feature registry for automatic approval reviews.
- Expose it as `features.guardianv2` in the configuration schema.
- Keep the under-development feature disabled by default.
GitOrigin-RevId: 92fa107e3ff1396a75a28a071353743a7bb48c43
## What changed
Skip registering the standalone `image_generation` tool when cached
authentication identifies the account plan as Free. Leave the existing
feature, provider capability, model modality, and authorization checks intact
for other account plans.
GitOrigin-RevId: 54d3b73dc610e508db7e281c4d7a8e72961e35a6
## Why
Parent context-window and auto-compaction overrides may describe a different
model than the one selected for Guardian review.
## What changed
- Clear `model_context_window` and `model_auto_compact_token_limit` when the
effective Guardian model differs from the parent model, allowing the review
model's own limits to apply.
- Preserve those overrides when Guardian uses the same effective model.
## Testing
Add unit coverage for both model-selection paths and verify that a Guardian
rollout records the selected review model's context window.
GitOrigin-RevId: ebc399f4eba37c7f279fd0d258154c00d45e2d00
## What changed
- Tell the model that generated images are already displayed to the user and should not be repeated as Markdown images or file links.
- Keep generated-image artifact paths and output hints owned by the image generation extension.
- Centralize the availability check for the image generation tool across feature, provider, namespace-tool, model modality, and authentication requirements.
## Testing
- Verify artifact paths sanitize session and call identifiers.
- Verify the model-facing output hint reports that the generated image is already displayed.
GitOrigin-RevId: 6c865b6a96d6a71bb2c33246d1518a00e7c8b840
## What changed
- On session startup, remove exact `allow` entries from `rules/default.rules`
for command prefixes that Codex no longer suggests as policy amendments.
- Record the migration in `.sandbox_migration` so it runs only once, preserving
rules created after the migration.
- Skip the migration when user and project exec policy rules are ignored.
- Expand the protected prefix list across shells, interpreters, package runners,
and destructive or privilege-related commands.
## Testing
- Cover selective removal, case-insensitive matching, one-time behavior, and the
startup path with ignored policy rules.
GitOrigin-RevId: a0c60e3f82b9630e621fd034b40462e3ab775102
## What changed
Update the image generation guidance to set a 120-second yield for the
initial code-mode call and subsequent waits, then return the completed result
with `generatedImage(result)`.
GitOrigin-RevId: 85041db27a0b41d830014984518d95fdd2875bed
## What changed
- Limit Guardian reviewer sessions with an environment to `exec_command`,
`write_stdin`, and `view_image`.
- Exclude general tool sources from Guardian reviewer tool planning.
## Testing
- Extend the Guardian request snapshot test to assert the exact model-visible
tool list.
GitOrigin-RevId: 80ba7011c23c32d163aaad906087fac396cc70fa
## What changed
Remove the image generation instruction that prohibited any response after an
image was generated.
GitOrigin-RevId: c779055da3142ba84cdbb9312e5f66b132f24b29
## Summary
- allow the standalone image-generation and web-search extensions for
the actor-authorized provider shape used by CCA
- preserve builtin `image_generation` and `web_search` for older models
and existing flows
- keep ordinary non-OpenAI providers excluded from both extensions
- remove only the image extension local managed-AuthManager requirement
that CCA cannot satisfy
- share actor-authorization detection through `ModelProviderInfo`
- keep Core tests focused on routing behavior and cover header-shape
edge cases in `model-provider-info`
- add a Responses Lite regression that verifies both
`image_gen.imagegen` and `web.run`
## Why
CCA uses a provider named `local` with `requires_openai_auth: false` and
a non-empty `x-openai-actor-authorization` header. Core accepts that
provider shape, but both extension provider-name gates rejected it;
image generation additionally required a Codex-managed login.
The standalone paths must coexist with existing builtin tools. New
Responses Lite models can receive `image_gen.imagegen` and `web.run`,
while older models continue using builtin tools.
## Impact
This enables both standalone extensions for CCA once installed
downstream, without removing or changing builtin-tool compatibility for
older models.
## Validation
- `just test -p codex-core
responses_lite_exposes_standalone_tools_for_actor_authorized_provider`
- `just test -p codex-core
responses_lite_uses_standalone_web_search_and_image_generation`
- `just test -p codex-core
hosted_tools_follow_provider_auth_model_and_config_gates`
- `just test -p codex-image-generation-extension`
- `just test -p codex-web-search-extension`
- `just test -p codex-model-provider-info`
- `just fmt`
- `git diff --check`
## Why
Some extension hosts need generated images returned without writing them
to the local filesystem or giving the model a local path.
## What changed
**tl;dr**: we now conduct all extension operations in the image gen
extension
- Let hosts provide an optional image save root when installing the
extension.
- Save images and return path hints only when a save root is configured.
- Return image data without saving or adding a path hint when no save
root is configured.
- Preserve the extension-provided `saved_path` instead of persisting
extension images again in core.
- Leave built-in image generation unchanged.
## Validation
- `just test -p codex-image-generation-extension`
- `just test -p codex-app-server
standalone_image_generation_returns_saved_path_hint_to_model`
- `just test -p codex-core
extension_tool_uses_granted_turn_permissions_without_local_persistence`
- `just test -p codex-core tools::handlers::extension_tools::tests`
- tested on CODEX CLI on both save_root: CODEX_HOME and None
- tested on CODEX APP on both as well
## Why
Som tools, such as history and notes, must remain top-level when MCP
deferral is enabled while staying unavailable through code-mode `exec`.
## What changed
- Added `features.code_mode.direct_only_tool_namespaces`.
- Classified matching MCP tools as `DirectModelOnly`.
- Kept those tools top-level in `code_mode_only`.
- Excluded them from `tool_search` deferral and the nested `exec`
surface.
- Updated the generated config schema.
## Validation
- `code_mode_only_exposes_direct_model_only_mcp_namespaces`
- `load_config_resolves_code_mode_config`
## Why
#27920 stopped persisting image-generation items unless their status was
`completed`, preventing failed standalone extension items with empty
results from being saved. Built-in image generation can instead emit a
terminal `response.output_item.done` containing a complete base64 PNG
while the item status remains `generating`. In that case, app-server
emits no `savedPath`, so Codex Apps can render the inline image but
cannot expose a file artifact.
## What changed
- Persist image-generation items whenever `result` contains image data.
Failed terminal items still have empty results and remain unpersisted.
- Update the existing built-in image-generation integration test to
cover a terminal `generating` item and verify both `saved_path` and the
written PNG bytes.
## Validation
- Confirmed with a raw built-in websocket trace: the image progressed
through `in_progress`, `generating`, and `partial_image`, then emitted
one `response.output_item.done` with `status: "generating"` and a
complete PNG result.
- `just test -p codex-core builtin_image_generation_call_persisted` is
currently blocked before test execution by a pre-existing compile error
in `thread-store/src/thread_metadata_sync.rs:171`.
## Why
We need request-level evidence for Guardian cases where
`codex-auto-review` is missing from the client-side model catalog and
the review falls back to the parent model.
## What changed
- Add `guardian_catalog_contains_auto_review` to Guardian Responses API
client metadata.
- Add `guardian_model_provider_id` to Guardian Responses API client
metadata.
- Keep review-session metadata optional so callers without metadata
preserve the existing `None` path.
- Add tests for override, normal preferred-model, and
missing-auto-review-catalog behavior.
## Validation
- `just test -p codex-core
guardian_review_records_missing_auto_review_model_in_request_metadata`
- `just test -p codex-core
guardian_review_uses_model_catalog_override_when_preferred_review_model_exists`
- `just test -p codex-core
guardian_review_uses_preferred_review_model_without_model_catalog_override`
- `git diff --check origin/main`
## Why
Standalone image generation emitted a started item but no terminal item
when the backend failed. Clients could leave the operation unresolved or
render it as successful.
## What changed
- Emit a terminal image-generation item with `status: "failed"` when
generation or editing fails.
- Skip image persistence for failed terminal items.
- Render failed image generation distinctly in TUI history.
- Preserve the status when handling live and replayed terminal items.
## Looks for TUI, App-Side change needed
<img width="867" height="89" alt="image"
src="https://github.com/user-attachments/assets/9e32342f-a982-411e-8498-456639fc468a"
/>
## Validation
- `just test -p codex-image-generation-extension`
- App-server image-generation tests
- Core stream-event tests
- TUI image-generation lifecycle and snapshot tests
- Scoped Clippy and formatting
## Why
Image generation used `std::fs::read` for referenced image paths, which
did not support environment-backed filesystems or their sandbox context.
## What changed
- Expose optional turn environments to extension tool calls.
- Include each environment’s ID, working directory, filesystem, and
sandbox context.
- Read referenced images through the selected environment filesystem.
- Keep sandbox usage at the extension call site so extensions can choose
the appropriate access mode.
- Consolidate image request construction into one async function.
- Add coverage for successful environment reads and read failures.
## Validation
- `cargo check -p codex-image-generation-extension --tests`
- `just fmt`
- `just bazel-lock-update`
- `just bazel-lock-check`
`just test -p codex-image-generation-extension` could not complete
because the build exhausted available disk space.
## Why
Image edits should use the exact images selected by the model instead of
inferring edit inputs from conversation history.
## What changed
- Replaced the image tool's `action` argument with optional
`referenced_image_paths`.
- Treats omitted or empty references as generation and populated
references as editing.
- Reads referenced absolute image paths and packages them as image data
URLs for the edit request.
- Removed the previous history-selection and image-count heuristics.
- Updated direct and code-mode tool instructions and calls.
- Added an app-server integration test covering an attached image routed
to the image edit endpoint.
## Validation
- Tested end-to-end on local `just codex` with copy pasted image,
attached image, etc.
- `just test -p codex-image-generation-extension`
- `just test -p codex-app-server
standalone_image_edit_uses_attached_model_visible_image`
- `just fix -p codex-image-generation-extension`
- `just bazel-lock-check`
## 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`
## Summary
Restore Windows coverage for standalone image generation in code mode.
The previous test executed a V8-backed code-mode cell on Windows CI,
where that runtime path is intentionally excluded because it is
unreliable. The test was then ignored entirely on Windows, removing
useful coverage.
This splits the test into two checks:
- All platforms verify that `image_gen__imagegen` is exposed to the
model when image generation is configured for code mode only.
- Non-Windows platforms continue to execute the full V8-backed flow and
verify that the nested image-generation call succeeds.
## Verification
- `just fmt`
- `git diff --check`
- `just test -p codex-app-server standalone_image_generation`
Result: 3 tests passed, plus the required bench smoke check.
## Why
Local image attachments include image bytes, but the adjacent
model-visible label omits the source path. Exposing the path lets
model-selected workflows refer back to the intended local image
explicitly.
## What changed
- Include an escaped `path` attribute in model-visible local image
opening tags.
- Reuse the path-aware marker generator in rollout coverage.
- Update protocol, replay, and rollout coverage for the new request
shape.
## Validation
- `just fmt`
- `just test -p codex-protocol`
- `just test -p codex-core skips_local_image_label_text`
- `just test -p codex-core
copy_paste_local_image_persists_rollout_request_shape`
- `git diff --check`
## 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`
## 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`
## Why
Guardian auto-review normally uses the provider-preferred review model
when one is available. Some parent models need model-catalog metadata to
select a different review model while keeping older `/models` payloads
compatible when that metadata is absent.
## What changed
- Added optional `ModelInfo::auto_review_model_override` metadata to the
public model payload as a review-model slug.
- Updated Guardian review model selection to prefer the catalog override
when present, while preserving the existing provider preferred-model
path and parent-model fallback when it is omitted.
- Added focused Guardian coverage for override and no-override model
selection.
- Added an `auto_review` core integration suite test that loads override
metadata from a remote model catalog path and asserts the strict
auto-review `/responses` request uses the catalog-selected review model.
- Updated existing `ModelInfo` fixtures and local catalog constructors
for the new optional field.
## Validation
- `cargo test -p codex-protocol
model_info_defaults_availability_nux_to_none_when_omitted`
- `cargo test -p codex-core guardian_review_uses_`
- `cargo test -p codex-core
remote_model_override_uses_catalog_model_for_strict_auto_review --test
all`
- `just fix -p codex-protocol`
- `just fix -p codex-core`
- `just fmt`
- `git diff --check`
## Why
`codex exec` was forcing headless runs to `approval_policy = "never"`
even when the resolved reviewer was `auto_review`. That prevented
unattended exec workflows from reaching the reviewed MCP write path they
were configured to use.
## What changed
- Keep the existing headless `never` default for ordinary exec runs.
- Re-resolve exec config without that synthetic override when the final
reviewer resolves to `AutoReview`, so configured or requirements-driven
approval policy is preserved.
- Add regression coverage for:
- `auto_review` plus `on-request` from user config
- requirements-driven `AutoReview`, asserting exec’s final approval
policy matches the no-override control config exactly
## Validation
- `just fmt`
- `cargo test -p codex-exec`
## 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`.
## 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>
## Why
Standalone image generation needs a typed `codex-api` client surface for
the Codex image proxy routes before the harness and model-facing tool
layers are wired in.
## What changed
- Added `ImagesClient` support for JSON `images/generations` and
`images/edits` requests.
- Added typed request and response shapes for generation, JSON edit
image URLs, image metadata, and base64 image outputs.
- Kept generation model slugs open-ended while requiring the generation
model field that the downstream endpoint expects.
- Exported the new client and image types from `codex-api`.
- Added coverage for generation and edit wire shapes, extra response
metadata that the client ignores, and malformed image responses missing
`data`.
## Validation
- `cargo test -p codex-api`
- `just fix -p codex-api`
- `just fmt`
- `git diff --check main`
## Why
Long-running turns can accumulate enough denied auto-review decisions to
trip the global short-circuit even when those denials are spread far
apart. The breaker should still stop genuinely bad loops, but it should
judge recent behavior instead of lifetime turn history.
## What changed
- Replaced the lifetime `10 total denials` threshold with `10 denials in
the last 50 reviews`.
- Kept the existing `3 consecutive denials` interrupt behavior
unchanged.
- Tracked recent auto-review outcomes in the circuit breaker and updated
the warning copy to report the rolling-window count.
- Renamed the new rolling-window coverage to `auto_review_*` test names.
- Added coverage that confirms older denials fall out of the 50-review
window and no longer trigger the breaker.
## Validation
- `just fmt`
- `cargo test -p codex-core guardian_rejection_circuit_breaker --lib`
- `cargo test -p codex-core auto_review_rejection_circuit_breaker --lib`
## Why
The TUI currently exposes overlapping command names for the same
permissions flow: `/permissions` and the older `/approvals` alias. It
also uses `/autoreview` for the manual retry flow, even though the
action users take there is approving one denied auto-review request.
This change makes the command surface consistent with the hard rebrand:
- `/permissions` is the only command for permission settings.
- `/approve` is the command for approving a recent auto-review denial.
## What changed
- Removed the legacy `/approvals` slash command and its dispatch path.
- Kept `/permissions` as the single permissions command shown and
accepted by the TUI.
- Renamed the auto-review denial command from `/autoreview` to
`/approve`.
- Updated nearby comments so they refer to `/permissions` rather than
the retired `/approvals` name.
## Verification
- Updated the slash-command unit test to assert that `AutoReview` now
renders and parses as `approve`.
## Summary
- include the live auto-review trunk rollout when `/feedback` uploads
logs
- upload that attachment as
`auto-review-rollout-<parent-thread-id>.jsonl` so it is distinguishable
from the parent rollout
- show the same auto-review attachment name in the TUI consent popup
## Scope
- this only covers the live cached auto-review trunk for the current
parent thread
- it does not add durable historical parent->auto-review lookup
- it does not add persisted rollout support for ephemeral parallel
review forks
## UI
<img width="599" height="185" alt="Screenshot 2026-04-28 at 1 17 18 PM"
src="https://github.com/user-attachments/assets/6a0e79c2-5d21-4702-8a89-f765778bc9e9"
/>
## Validation
- `cargo test -p codex-core
cached_guardian_subagent_exposes_its_rollout_path`
- `cargo test -p codex-feedback`
- `cargo test -p codex-app-server`
- `cargo test -p codex-tui feedback_upload_consent_popup_snapshot`
- `cargo test -p codex-tui
feedback_good_result_consent_popup_includes_connectivity_diagnostics_filename`
## Known unrelated local failures
- `cargo test -p codex-core` currently fails in the pre-existing proxy
env snapshot test
`tools::runtimes::tests::maybe_wrap_shell_lc_with_snapshot_keeps_user_proxy_env_when_proxy_inactive`
- `cargo test -p codex-tui` currently hits pre-existing `status::*`
snapshot drift unrelated to this change
## Follow-Up
- persist parallel auto-review fork sessions so /feedback can include
their rollout history too
- attach each persisted fork as its own clearly named file, for example
auto-review-rollout-<parent-thread-id>-fork <n>.jsonl, instead of
merging multiple Guardian sessions into one attachment
- keep the same live-session-only scope initially; durable historical
parent -> auto-review lookup can remain a separate decision if we later
need feedback from resumed sessions
## Why
Auto-review can deny an action that the user later decides they want to
retry. Today there is no TUI surface for selecting a recent denial and
sending explicit approval context back into the session, so users have
to restate intent manually and the retry can be reviewed without the
original denied action context.
This adds a narrow TUI-driven path for approving a recent denied action
while still keeping the retry inside the normal auto-review flow.
## What Changed
- Added `/auto-review-denials` to open a picker of recent denied
auto-review actions.
- Added a small in-memory TUI store for the 10 most recent denied
auto-review events.
- Selecting a denial sends the structured denied event back through the
existing core/app-server op path.
- Core now injects a developer message containing the approved action
JSON rather than the full assessment event.
- Auto-review transcript collection now preserves this specific approval
developer message so follow-up review sessions can see the user approval
context.
- Added TUI snapshot/unit coverage for the picker and approval dispatch
path.
- Added core coverage for retaining the approval developer message in
the auto-review transcript.
## Verification
- `cargo test -p codex-core
collect_guardian_transcript_entries_keeps_manual_approval_developer_message`
- `cargo test -p codex-tui auto_review_denials`
- `cargo test -p codex-tui
approving_recent_denial_emits_structured_core_op_once`
## Notes
This intentionally keeps retries going through auto-review. The approval
signal is context for the exact previously denied action, not a blanket
bypass for similar future actions.
## Why
This keeps the partial Guardian subagent -> Auto-review rename
forward-compatible across mixed Codex installations. Newer binaries need
to understand the new `auto_review` spelling, but they cannot write it
to shared `~/.codex/config.toml` yet because older CLI/app-server
bundles only know `user` and `guardian_subagent` and can fail during
config load before recovering.
The Python SDK had the opposite compatibility gap: app-server responses
can contain `approvalsReviewer: "auto_review"`, but the checked-in
generated SDK enum did not accept that value.
## What Changed
- Keep `ApprovalsReviewer::AutoReview` readable from both
`guardian_subagent` and `auto_review`, while serializing it as
`guardian_subagent` in both protocol crates.
- Update TUI Auto-review persistence tests so enabling Auto-review
writes `approvals_reviewer = "guardian_subagent"` while UI copy still
says Auto-review.
- Map managed/cloud `feature_requirements.auto_review` to the existing
`Feature::GuardianApproval` gate without adding a broad local
`[features].auto_review` key or changing config writes.
- Add `auto_review` to the Python SDK `ApprovalsReviewer` enum and cover
`ThreadResumeResponse` validation.
## Testing
- `cargo test -p codex-protocol approvals_reviewer`
- `cargo test -p codex-app-server-protocol approvals_reviewer`
- `cargo test -p codex-tui
update_feature_flags_enabling_guardian_selects_auto_review`
- `cargo test -p codex-tui
update_feature_flags_enabling_guardian_in_profile_sets_profile_auto_review_policy`
- `cargo test -p codex-core
feature_requirements_auto_review_disables_guardian_approval`
- `pytest
sdk/python/tests/test_client_rpc_methods.py::test_thread_resume_response_accepts_auto_review_reviewer`
- `git diff --check`
## Why
`approvals_reviewer` now uses `auto_review` as the canonical config/API
value after #18504, but the Rust enum variant and nearby helper/test
names still used `GuardianSubagent` / guardian approval wording. That
made follow-up code and reviews confusing even though the external value
had already moved to Auto-review.
## What changed
- Renamed `ApprovalsReviewer::GuardianSubagent` to
`ApprovalsReviewer::AutoReview`.
- Updated protocol, app-server, config, core, TUI, exec, and analytics
test callsites.
- Renamed nearby helper/test names from guardian approval wording to
Auto-review wording where they refer to the approvals reviewer mode.
- Preserved wire compatibility:
- `auto_review` remains the canonical serialized value.
- `guardian_subagent` remains accepted as a legacy alias.
This intentionally does not rename the `[features].guardian_approval`
key, `Feature::GuardianApproval`, `core/src/guardian`, analytics event
names, or app-server Guardian review event types.
## Verification
- `cargo test -p codex-protocol
approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
- `cargo test -p codex-app-server-protocol
approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
- `cargo test -p codex-config approvals_reviewer`
- `cargo test -p codex-tui update_feature_flags`
- `cargo test -p codex-core permissions_instructions`
- `cargo test -p codex-tui permissions_selection`
### Why
Auto-review is the user-facing name for the approvals reviewer, but the
config/API value still exposed the old `guardian_subagent` name. That
made new configs and generated schemas point users at Guardian
terminology even though the intended product surface is Auto-review.
This PR updates the external `approvals_reviewer` value while preserving
compatibility for existing configs and clients.
### What changed
- Makes `auto_review` the canonical serialized value for
`approvals_reviewer`.
- Keeps `guardian_subagent` accepted as a legacy alias.
- Keeps `user` accepted and serialized as `user`.
- Updates generated config and app-server schemas so
`approvals_reviewer` includes:
- `user`
- `auto_review`
- `guardian_subagent`
- Updates app-server README docs for the reviewer value.
- Updates analytics and config requirements tests for the canonical
auto_review value.
### Compatibility
Existing configs and API payloads using:
```toml
approvals_reviewer = "guardian_subagent"
```
continue to load and map to the Auto-review reviewer behavior.
New serialization emits:
```toml
approvals_reviewer = "auto_review"
```
This PR intentionally does not rename the [features].guardian_approval
key or broad internal Guardian symbols. Those are split out for a
follow-up PR to keep this migration small and avoid touching large
TUI/internal surfaces.
**Verification**
cargo test -p codex-protocol
approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent
cargo test -p codex-app-server-protocol
approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent
## Summary
This adds the structural plumbing needed for an app-server client to
approve a previously denied Guardian review and carry that approval
context into the next model turn.
This PR does not add the actual `/auto-review-denials` tool
## What Changed
- Added app-server v2 RPC `thread/approveGuardianDeniedAction`.
- Added generated JSON schema and TypeScript fixtures for
`ThreadApproveGuardianDeniedAction*`.
- Added core `Op::ApproveGuardianDeniedAction`.
- Added a core handler that validates the event is a denied Guardian
assessment and injects a developer message containing the stored denial
event JSON.
- Queues the approval context for the next turn if there is no active
turn yet.
- Added the TUI app-server bridge so `Op::ApproveGuardianDeniedAction {
event }` is routed to the app-server request.
## What This Does Not Do
- Does not add `/auto-review-denials`.
- Does not add chat widget recent-denial state.
- Does not add popup/list UI.
- Does not add a product-facing denial lookup/store.
- Does not change where Guardian denials are originally emitted or
persisted.
## Verification
- `cargo test -p codex-tui thread_approve_guardian_denied_action`
## Summary
This makes `DangerFullAccess` / yolo tool execution fully opt out of
managed-network enforcement.
Previously, yolo turns could have `turn.network` stripped while tool
orchestration still derived `enforce_managed_network=true` from
`requirements.toml.network`. That created an inconsistent state where
the turn had no managed proxy attached, but tool execution still behaved
like managed networking was active.
This updates the tool orchestration and JS REPL paths to treat managed
networking as active only when the current turn actually has
`turn.network`.
## Behavior
- Yolo / `DangerFullAccess`: no managed proxy, no managed-network
enforcement.
- Guardian / workspace-write with managed proxy: managed-network
enforcement still applies.
- Avoids the half-state where yolo has no proxy but still gets
managed-network sandbox behavior.
## Tests
- `just fmt`
- `cargo test -p codex-core
danger_full_access_tool_attempts_do_not_enforce_managed_network --
--nocapture`
- `cargo test -p codex-core danger_full_access -- --nocapture`
- `just fix -p codex-core`
Co-authored-by: jgershen-oai <jgershen@openai.com>
## Summary
- Promote `image_generation` from under-development to stable
- Enable image generation by default in the feature registry
- Update feature coverage for the new launch-state expectation
- Add the missing image-generation auth fixture field in a tool registry
test
## Testing
- `just fmt`
- `cargo test -p codex-features`
- `cargo test -p codex-tools` currently fails:
`test_full_toolset_specs_for_gpt5_codex_unified_exec_web_search` needs
its expected default tool list updated for `image_generation`
**Summary**
- prevent managed requirements.toml network settings from leaking into
DangerFullAccess / yolo turns by gating managed proxy attachment on
sandbox mode
- keep guardian/sandboxed modes on the managed proxy path, while making
true yolo bypass the proxy entirely, including /shell full-access
commands
### **Issue**
guardian_parallel_reviews_fork_from_last_committed_trunk_history was
failing on Windows/Bazel with a stack overflow:
`thread
'guardian::tests::guardian_parallel_reviews_fork_from_last_committed_trunk_history'
has overflowed its stack`
- This problem was a stack-headroom problem
### **Solution**
Reduced stack pressure in the guardian async path by boxing thin wrapper
futures, and run the affected test on a dedicated 2 MiB thread stack.
Concretely:
- added Box::pin(...) around thin async wrapper hops in the guardian
review/delegate path
- changed
guardian_parallel_reviews_fork_from_last_committed_trunk_history to run
inside an explicitly sized thread stack so it has enough headroom in
low-stack environments
This PR teaches the TUI to render guardian review timeouts as explicit
terminal history entries instead of dropping them from the live
timeline.
It adds timeout-specific history cells for command, patch, MCP tool, and
network approval reviews.
It also adds snapshot tests covering both the direct guardian event path
and the app-server notification path.
## Summary
- update the guardian timeout guidance to say permission approval review
timed out
- simplify the retry guidance to say retry once or ask the user for
guidance or explicit approval
## Testing
- cargo test -p codex-core
guardian_timeout_message_distinguishes_timeout_from_policy_denial
- cargo test -p codex-core
guardian_review_decision_maps_to_mcp_tool_decision
**Summary**
This PR treats Guardian timeouts as distinct from explicit denials in
the core approval paths.
Timeouts now return timeout-specific guidance instead of Guardian
policy-rejection messaging.
It updates the command, shell, network, and MCP approval flows and adds
focused test coverage.
## Summary
- Add `TimedOut` to Guardian/review carrier types:
- `ReviewDecision::TimedOut`
- `GuardianAssessmentStatus::TimedOut`
- app-server v2 `GuardianApprovalReviewStatus::TimedOut`
- Regenerate app-server JSON/TypeScript schemas for the new wire shape.
- Wire the new status through core/app-server/TUI mappings with
conservative fail-closed handling.
- Keep `TimedOut` non-user-selectable in the approval UI.
**Does not change runtime behavior yet; emitting `TimeOut` and
parent-model timeout messaging will come in followup PRs**
## Summary
This PR adds the parent conversation/session id to the subagent-start
analytics event for Guardian subagents.
Previously, Guardian sessions were emitted as subagent
thread-initialized events, but their `parent_thread_id` was serialized
as `null`. After this change, the `codex_thread_initialized` analytics
event for a Guardian child session includes the parent user conversation
id.
## Summary
- add the missing `image_generation_tool_auth_allowed` field to the new
tool registry plan test initializer
## Validation
- `just fmt`
- `cargo test -p codex-tools image_generation`
- `cargo test -p codex-tools --no-run`
**Disabling Image-Gen for Non-SIWC Codex Users**
We are only enabling image-gen feature for SIWC Codex users until there
comes a fix in ResponsesAPI to omit output from responses.completed, to
prevent the following issues:
1. websocket blows up due to heavier load (images) than before (text)
2. http parser streams through n^2 of n-base64 bytes (sum of base64s of
all images generated in turn) that causes long delays in
turn_completion.
Won Park