Support secure imagegen output rendering for third-party Codex providers #68

Objective

Make image-generation results produced through a third-party Codex Responses provider render correctly in the Codex App when the provider requires an actor-authorization compatibility header. CodexHub should manage this safely instead of requiring users to hand-edit secret-bearing config.toml entries.

Source and reported behavior

External report: https://x.com/1999_eth/status/2075949033215148245

The report claims that, in newer Codex App builds, imagegen may finish successfully through a third-party API while the resulting image does not appear in the client. Its reported workaround combines:

• requires_openai_auth = false; and
• an http_headers entry for x-openai-actor-authorization.

Treat this as a reproduction lead, not a verified protocol contract. Do not copy the post's provider-specific URL, token, or header value into defaults, fixtures, logs, or documentation.

CodexHub currently generates provider configuration with requires_openai_auth = true and does not manage this header. The exact failing boundary—Codex Desktop, Codex Core, CodexHub Gateway, upstream generation, or artifact retrieval—must be proven before implementation.

Required investigation

• Reproduce against a pinned Codex App version using:
  • official OpenAI behavior as the control;
  • a native third-party Responses provider directly; and
  • the same provider through CodexHub Gateway.
• Capture sanitized request, response, SSE, and image/artifact retrieval traces.
• Identify which component consumes x-openai-actor-authorization, what value semantics it expects, and which requests receive it.
• Determine whether requires_openai_auth = false is actually necessary, and ensure this does not weaken CodexHub's local Gateway authentication from Harden local Gateway auth so codex-app context is not spoofable #24.
• Distinguish provider-hosted image execution from the local imagegen skill and client-side image presentation.
• Verify behavior on Windows and, where practical, macOS/Linux configuration paths.
• Record the exact Codex build because this may be a version-specific closed-client behavior.

Intended product behavior

After the evidence establishes the contract:

• add an explicit, per-provider image-output compatibility capability instead of globally injecting the header;
• write and restore the required Codex configuration atomically using the existing overlay lifecycle;
• source authorization values from protected provider credentials rather than duplicating plaintext secrets where possible;
• redact the header and derived credentials from diagnostics, exports, logs, telemetry, and error messages;
• expose a clear UI state or diagnostic when the provider cannot support image output;
• require a deliberate opt-in until the compatibility behavior is proven safe across providers;
• preserve official OpenAI behavior and providers that do not need the compatibility path.

Acceptance criteria

• A pinned-version reproduction demonstrates the original “generation completes but image is not displayed” failure.
• Sanitized evidence identifies the failing component and the exact request/header contract.
• Image output from a supported third-party Responses provider is displayed in Codex App through CodexHub.
• The feature is configured per provider and does not inject the header into unrelated or official requests.
• No provider key or actor-authorization value appears in logs, telemetry, exports, UI error text, tests, or committed fixtures.
• Enabling the feature does not bypass or regress local Gateway authentication.
• Config writes, switching providers, disable/restore, restart, and crash recovery preserve the atomicity expectations from Make config and catalog writes atomic and locked across Rust and Python #23.
• Missing, rejected, or unsupported authorization produces an actionable diagnostic rather than a silent missing image.
• Automated tests cover config generation/redaction and the relevant request or artifact-retrieval path.
• User documentation explains the compatibility option without recommending hard-coded third-party secrets.

Related

• Make config and catalog writes atomic and locked across Rust and Python #23
• Harden local Gateway auth so codex-app context is not spoofable #24
• Spike complete Codex model capability exposure on third-party providers #57
• 0.1.8 Beta2: Define tool-type compatibility rules for custom Responses endpoints #65
• src-python/config_overlay.py
• src-tauri/src/proxy.rs