hermes - 💡(How to fix) Fix [Feature]: Surface the bundled openai-codex image_gen plugin in the hermes tools picker so Codex subscribers don't need FAL_KEY [1 participants]

Problem or Use Case

I'm on a paid ChatGPT/Codex subscription and have already signed in via hermes auth codex (so openai-codex works as my chat provider). I want image generation to use the same Codex subscription I'm already paying for, without configuring a FAL_KEY and without paying FAL per-image on top.

The plumbing for this already exists — plugins/image_gen/openai-codex/ (shipped in v0.11.0 via #14317) generates gpt-image-2 through the Codex Responses image_generation tool using the same OAuth credentials. But hermes tools → 🎨 Image Generation only shows two rows:

# hermes_cli/tools_config.py — TOOL_CATEGORIES["image_gen"]
{"name": "Nous Subscription",  "imagegen_backend": "fal", ...},
{"name": "FAL.ai", "env_vars": [{"key": "FAL_KEY", ...}], "imagegen_backend": "fal"},

Both are FAL-backed, and the FAL.ai row prompts for FAL_KEY. There is _plugin_image_gen_providers() that injects registered plugin backends into the picker, but in practice (at least for me on the current main) the openai-codex backend doesn't surface as a selectable option, so the picker pushes me toward FAL even though Codex would work for free under my existing subscription.

Proposed Solution

Add a first-class picker row for the Codex-auth backend in TOOL_CATEGORIES["image_gen"], alongside Nous Subscription and FAL.ai:

{
    "name": "OpenAI (Codex auth)",
    "badge": "subscription",
    "tag": "gpt-image-2 via ChatGPT/Codex OAuth — no API key needed",
    "env_vars": [],
    "imagegen_backend": "openai-codex",
    "image_gen_plugin_name": "openai-codex",
    # gate on the same check the plugin's is_available() uses, so
    # the row is hidden for users who have not run `hermes auth codex`
    "requires_codex_auth": True,
},

Picking it should:

1. Write image_gen.provider: openai-codex (and optionally image_gen.openai-codex.model) into config.yaml.
2. Skip the FAL_KEY prompt entirely for this backend.
3. Then run the existing per-model picker (Low / Medium / High — _MODELS from plugins/image_gen/openai-codex/__init__.py).

Availability gate should mirror OpenAICodexImageGenProvider.is_available() — i.e. _read_codex_access_token() returns a token AND openai is importable — so the row only appears for users who actually have Codex auth set up.

Bonus: if a user already has hermes auth codex working but no FAL_KEY, recommend the Codex backend as the default selection in the picker (the way "★ recommended" already works for the local browser row).

Alternatives Considered

• Rely on _plugin_image_gen_providers() discovery only. This is the existing path, but in practice the Codex plugin doesn't show up as a selectable picker entry on a fresh install for me, and even if it did, the picker still has FAL hard-coded as the "obvious" choice. A hard-coded TOOL_CATEGORIES row gives the option real visibility and a deterministic config write.
• Tell users to set image_gen.provider: openai-codex manually in config.yaml. Works, but it's invisible to users who don't read the developer docs, and it requires knowing the plugin exists.

If the registry-discovery path is intended to be the long-term answer here, then this issue can be downscoped to: "openai-codex should auto-register and auto-rank above FAL in _visible_providers when Codex auth is configured and FAL_KEY isn't".

Feature Type

• CLI improvement

Scope

• Small (one new entry in TOOL_CATEGORIES["image_gen"] + a visibility predicate that checks _read_codex_access_token()).

Related

• v0.11.0 release notes — openai-codex image_gen plugin (gpt-image-2 via Codex OAuth) (#14317)
• plugins/image_gen/openai-codex/__init__.py — provider already wired
• hermes_cli/tools_config.py — where the new row would live
• tests/hermes_cli/test_image_gen_picker.py — already covers plugin-injection in the picker; a similar test for the new row would slot in here

I'd be happy to take a stab at the PR if the approach above is acceptable.