Ollama Gemma4 修復と Codex 制御プレーンを追加

[Voicle99]

概要

Hermes WebUI で発生していた Ollama/Gemma4 系の表示・応答停止問題を修正し、追加で Hermes から OpenAI Codex を直接制御できる control plane を導入します。

この PR は以下を同時に固定します。

1. gemma4:26b がモデル一覧に出ない / 送っても本文応答が見えない問題
2. provider/profile/model cache の混線による再発
3. Hermes WebUI から Codex のモデル一覧・reasoning effort を選択できない問題

変更点

Ollama / Gemma4 修正

• ollama / ollama-local / local-ollama を WebUI catalog 上で custom に潰さず保持
• providers.ollama-local のような named local/OpenAI-compatible provider を /api/models と /api/models/live に反映
• /api/models/live?provider=ollama-local に cold-start fallback を追加
• モデル一覧キャッシュを config path + mtime 単位で分離
• @ollama-local:gemma4:26b のような prefixed model でも profile auto-switch が効くように修正
• streaming runtime provider を ollama-local から Hermes runtime の custom transport に正しく寄せる
• agent.reasoning_effort 読取バグを修正
• native confirm() を shared dialog に置換
• Ollama/Gemma4 再発防止テストを追加

Codex control plane 追加

• Codex catalog を WebUI 側で live/cache/static fallback の3段構えに変更
  • live: Hermes agent の provider_model_ids("openai-codex")
  • cache/config: ~/.codex の local cache/config
  • fallback: WebUI の拡張 Codex catalog
• /api/codex/capabilities を追加
  • provider / api_mode / credential_pool / model list / reasoning efforts / auth status を返す
  • secret や auth store path は返さない
• /api/codex/select を追加
  • model.provider=openai-codex
  • model.base_url=https://chatgpt.com/backend-api/codex
  • model.default=<selected codex model>
  • agent.reasoning_effort=<none|minimal|low|medium|high|xhigh>
    を一括保存
• WebUI slash command /codex [model] [effort] を追加
  • 引数なし: Codex status / model count / auth / current reasoning を表示
  • 例: /codex gpt-5.3-codex-spark xhigh
• /codex autocomplete 用に Codex 専用 model source を追加
• openai-codex を provider mismatch 判定上は OpenAI family として扱い、Codex active 時に bare gpt-* を誤警告しないよう修正
• Korean locale coverage test に合わせて cmd_codex 翻訳キーを追加

検証

• python3 -m py_compile api/config.py api/routes.py
• node --check static/commands.js
• node --check static/ui.js
• python -m pytest tests/ -q
  • 2857 passed, 1 warning, 8 subtests passed
  • 既存 warning: tests/test_onboarding_network.py:134 の unknown integration mark

実動確認

• Hermes WebUI launchd を再起動
• /health が status=ok
• /api/codex/capabilities?live=0
  • provider=openai-codex
  • api_mode=codex_responses
  • model_count=18
  • gpt-5.3-codex-spark を含む
  • reasoning efforts: none/minimal/low/medium/high/xhigh
  • auth response keys は authenticated/error/key_source のみ
• active profile は tom-claude に復元済み

追加ガードレール

• tests/test_ollama_gemma4_guardrails.py
  • _cfg.cfg 読取禁止
  • named local provider → runtime custom transport
  • local Ollama live model fallback
  • profile/config 跨ぎの disk cache 混線防止
  • tom-claude と ollama-gemma4 相当の catalog 混線防止
• tests/test_codex_control_plane.py
  • Codex fallback catalog の網羅性
  • /api/codex/capabilities route
  • /api/codex/select route
  • Codex provider/model/base_url/reasoning の config 永続化
  • effort-only switch 時も非Codex既定モデルを持ち越さない
  • /api/models/live?provider=openai-codex が Codex catalog を使う
  • /codex slash command wiring
  • openai-codex provider mismatch 誤警告防止

[Voicle99]

追加対応しました。\n\n- upstream master (24b1e6f) に rebase 済み\n- conflict 解消済み\n- PR 状態: MERGEABLE\n- ローカル全テスト: 2848 passed, 1 warning, 8 subtests passed\n\nなお、こちらのGitHub権限では upstream の MergePullRequest を実行できませんでした。maintainer権限を持つ方のmerge操作が必要です。

[Voicle99]

追加実装・監査完了です。\n\n## 追加内容\n- Hermes WebUI に Codex control plane を導入しました。\n- /api/codex/capabilities で Codex provider / api_mode / credential_pool / model list / reasoning efforts / auth status を取得できます。\n- /api/codex/select で model.provider=openai-codex、Codex base URL、既定モデル、reasoning effort を一括保存できます。\n- WebUI slash command /codex [model] [effort] を追加しました。例: /codex gpt-5.3-codex-spark xhigh\n- Codex model catalog は live / local Codex cache / WebUI fallback を merge します。\n- openai-codex active 時に bare gpt-* モデルで provider mismatch 誤警告が出ないようにしました。\n\n## 検証\n- python3 -m py_compile api/config.py api/routes.py\n- node --check static/commands.js\n- node --check static/ui.js\n- python -m pytest tests/ -q\n - 2857 passed, 1 warning, 8 subtests passed\n - warning は既存の unknown pytest mark integration です。\n\n## 実動確認\n- Hermes WebUI launchd restart 済み\n- /health: ok\n- /api/codex/capabilities?live=0:\n - provider: openai-codex\n - api_mode: codex_responses\n - model_count: 18\n - gpt-5.3-codex-spark 含有\n - reasoning efforts: none/minimal/low/medium/high/xhigh\n - auth response は authenticated/error/key_source のみで、auth store path は露出しません。\n\n現時点で PR は mergeable です。

[Voicle99]

マージ再実行も確認しましたが、権限でブロックされています。\n\nGraphQL: Voicle99 does not have the correct permissions to execute MergePullRequest\n\nPR は mergeable です。リポジトリ write/maintainer 権限を持つユーザーによる merge が必要です。

[nesquena-hermes]

Thanks for the detailed PR, @Voicle99! This is a substantial contribution combining Ollama/Gemma4 fixes with a new Codex control plane. Let me share some review thoughts:

Ollama/Gemma4 fixes

The diagnosis — ollama-local being collapsed to custom in the catalog, and per-config-path cache isolation — looks correct for the symptoms described. A few things to verify:

1. Cache isolation key: The PR notes the model list cache is now keyed by config path + mtime. Confirming the mtime is checked at read time (not just at population time) so stale cached results are invalidated when the config file changes on disk.

2. @ollama-local:gemma4:26b profile auto-switch: The prefixed model format for profile switching is a new parsing path. Please confirm the prefix parser is tested for malformed inputs (missing colon, unknown provider prefix) so it fails gracefully rather than silently switching to the wrong profile.

Codex control plane

The /api/codex/capabilities and /api/codex/select endpoints are a meaningful addition. Some questions:

3. /api/codex/select persistence scope: The endpoint saves model.provider=openai-codex, model.base_url, and agent.reasoning_effort to config. Does this write to the active profile's config or a global config? If it's profile-scoped, confirming the write targets the correct profile (not the process-default) when multiple profiles are configured.

4. Auth status in /api/codex/capabilities: The PR notes the response only returns authenticated/error/key_source (no secrets or store paths). Confirming there's no code path that could leak the key itself, even in error messages.

5. /codex slash command: With no args, shows current status. With [model] [effort], applies them. If the user passes an unknown model name, what's the error response?

Test results

2857 passed / 0 failed (full suite) is a solid signal for a 10-file, 1457-line PR. The dedicated test files (test_ollama_gemma4_guardrails.py, test_codex_control_plane.py) provide good targeted coverage.

The PR is large — 10 files touched, mixing bug fixes and a new feature. If the maintainer wants to split Ollama fixes from the Codex control plane into separate PRs for easier review, that's worth considering. But both sets of changes are clearly described.

Regarding the merge permission error — that's expected for contributor accounts. A maintainer with repo write access will handle the merge once the PR is approved.

[nesquena-hermes]

Hold — review questions outstanding

Thanks for the extensive PR, @Voicle99! The Ollama/Gemma4 fixes look solid and the Codex control plane is an interesting addition.

Before this can proceed, please address the questions from the review comment (posted 2026-04-28):

1. Codex control plane scope — /api/codex/capabilities and /api/codex/select are substantial new endpoints. Please confirm: are these endpoints only exposed when openai-codex is an active provider, or are they always present? Unauthenticated endpoints that reveal provider config details could be a concern.
2. /codex slash command — does this conflict with any existing slash command routing? Please confirm the command is registered through the normal slash-command pipeline and appears in /help.
3. Test coverage — the PR reports 2857 passed but the test file names suggest they test the new Codex endpoints directly. Please confirm the existing Ollama/provider tests still pass unchanged.
4. Profile isolation — the PR mentions per-config-path disk cache isolation. Please confirm this doesn't accidentally share cache across profiles with the same config path.

Please respond to these points and we'll do a full diff review.

[nesquena-hermes]

Maintainer fit-review needed — splitting Ollama fixes from Codex control plane

Adding maintainer-review while we evaluate scope. Two separable concerns are bundled into a single PR:

1. Ollama / Gemma4 fixes — ollama-local provider catalog collapse, gemma4:26b not appearing in dropdown, response-stream silence. These are real bugs and we want them.

2. Codex control plane (new feature surface) — /api/codex/capabilities, /api/codex/select, plus the credential-pool / api-mode / reasoning-effort plumbing. This is a substantial new product surface, not a bug fix. It needs its own design review (does the WebUI want a per-provider control plane abstraction? does it conflict with the in-app device-flow / OAuth path that shipped in v0.50.257? are the new endpoints behind the existing auth gate?).

Ask: Could you split this into two PRs?

• PR A — just the Ollama / Gemma4 catalog + streaming fixes (~few hundred LOC). We'd merge that quickly.
• PR B — the Codex control plane. We'll review it as a feature proposal — and may push back on scope or shape before it can be merged.

Bundling them together blocks the Ollama fix on a feature decision that may take a while. The split lets the bug fixes ship now and lets the control plane get the design discussion it deserves.

Tagging maintainer-review to flag the second half as not-yet-decided. Keeping hold until either it's split or we agree on the whole shape.

[nesquena-hermes]

Closing — scope is too entangled to salvage cleanly

Thanks @Voicle99 for the detailed PR. After running the salvage screen on this one, we're closing without merging or pulling sub-pieces, and want to be honest about why.

The scope problem

The PR bundles two distinct concerns:

1. Ollama / Gemma4 catalog and streaming fixes — real bugs, worth fixing
2. Codex control plane — substantial new product surface (/api/codex/capabilities, /api/codex/select, dynamic model/reasoning effort selection)

We asked for a split a few days ago and didn't hear back. We could have absorbed the split ourselves, but when we tried to extract just the Ollama half, we found the implementation isn't actually small atomic pieces:

• ~579 LOC of new infrastructure in api/config.py alone (_LOCAL_OLLAMA_ALIASES, _looks_like_ollama_provider, _looks_like_local_compat_provider, _get_provider_config helper, alias-table changes, provider-resolution path changes)
• ~200 LOC in api/routes.py for the model-resolver and Codex control endpoints
• 130 LOC of new static/commands.js for the Codex selection UI
• Plus i18n + boot.js + ui.js + streaming.py changes interleaved across both halves

Pulling the Ollama half cleanly would require redesigning the helper structure to not depend on the control-plane scaffolding. At that point we're rewriting it, not salvaging it. Per our salvage policy — when extracting a "small piece" requires also pulling helper functions and state variables, it's not salvage, it's just rebuilding.

Why the underlying Ollama bugs may still be worth fixing

If the specific Gemma4-not-in-dropdown bug still reproduces on master (v0.50.269), we'd welcome a small focused PR scoped to JUST that fix — likely 20-50 LOC adding the missing alias mappings without the broader catalog refactor. Same for the Ollama-not-streaming bug if you can isolate it.

Why we're closing rather than continuing to wait

The PR has been stale for 4 days with the split request unanswered. Holding it open longer doesn't help anyone — the underlying bugs (if real) are easier to fix from scratch than to extract from the current shape. And the Codex control plane half needs a separate design conversation we haven't had yet.

Path forward

If you'd still like to contribute:

• File a bug issue with a minimal reproduction of the Gemma4-not-in-dropdown problem (your config, what command you ran, what you see vs expect). Whoever picks it up — you, us, or another contributor — can write a focused fix.
• Open a separate design discussion issue for the Codex control plane direction if you still want to pursue it. We'd want to scope the conversation around: does the WebUI need a per-provider control-plane abstraction, what's the relationship to the device-flow OAuth path that shipped in v0.50.257, what's the auth gate for new endpoints. With alignment on that we'd be in a much better position to review a focused implementation.

Apologies for not engaging more deeply on the split request before closing. The scope as proposed wasn't going to make it through review even with the split, and we should have surfaced that earlier instead of waiting on you to do work we'd then push back on. Thanks for the contribution and for engaging with our review process — please keep contributing.