Problem or Use Case

Hermes already supports image generation, but openai-codex is not currently available as an image generation backend.

This creates a gap for users who already use Codex-related authentication or model routing in Hermes and want image generation to work through the same system. At the moment, there is no built-in way to select Codex as the backend for image generation, even though Codex/OpenAI supports image generation capabilities.

The main issue is not that image generation is missing entirely, but that Hermes cannot use Codex as one of its valid backends for that feature. That makes backend selection less flexible and prevents users from keeping this workflow inside Hermes’ normal tool and configuration model.

Proposed Solution

Add openai-codex as a supported backend for Hermes image generation.

At a high level, this would mean:

• allowing Codex to be selected as an image generation backend
• sending image generation requests through the OpenAI/Codex Responses API path
• handling generated image results in the same general way Hermes handles outputs from existing image backends
• keeping the public interface consistent so users do not need a separate workflow for Codex-backed image generation

Based on the current implementation and upstream Codex behavior, this looks feasible.

A few relevant details:

• Upstream Codex enables image generation in ChatGPT auth mode:
  • image_generation_tool_auth_allowed(...) checks for AuthMode::Chatgpt
• Codex models image generation responses as image_generation_call items with fields like:
  • id
  • status
  • revised_prompt
  • result
• result appears to contain the generated image payload
• Hermes’ current Codex/OpenAI adapter already iterates over Responses API output items, but it currently handles text messages and function_call items, not image_generation_call

That suggests the implementation could be something like:

1. extend the image generation tool/backend selection so openai-codex is valid
2. route that backend through the Responses API image generation path
3. parse image_generation_call outputs
4. decode/save the returned image
5. return the image file using Hermes’ existing output conventions

This seems cleaner than introducing a separate Codex-specific user workflow.

Alternatives Considered

1. Continue supporting only the current image generation backends
   This keeps the implementation simpler, but it leaves out a backend that is likely useful to some existing Hermes users.

2. Add this only as documentation or a skill-based workaround
   That may be enough for some advanced users, but it does not provide a proper built-in backend and does not solve the general product gap.

3. Introduce a separate Codex-specific image generation path instead of a normal backend
   That would likely add unnecessary special handling. Treating Codex as another backend seems cleaner and more consistent with how Hermes already approaches provider/tool abstractions

Feature Type

New tool

Scope

Large (new module or significant refactor)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)