Environment
- Windows 11, CodexHost 0.10.0 (installer + npm CLI 0.10.0), Codex Desktop, Hermes harness
- GLM Coding Plan subscription (BigModel), plus a zai API-key channel
Summary (user-verified across multiple runs)
The same machine, same Hermes engine, two auth paths — opposite outcomes:
- zai API-key path works. CLI delegation
codexhost delegate start --harness hermes --model <zai:glm-5.3-flash bare ref> → completed, reply "READY". UI sessions on zai / glm-5.3-flash also work.
- GLM Coding Plan path fails. Sessions created via the Coding-Plan-backed model entry (
zp / glm-5.3-flash in the picker) fail at spawn with the generic "Unable to start this chat" — reproducible every time, zero model output.
- The same Coding Plan works in standalone Hermes. The native Hermes app on the same machine, with the same plan login, connects and streams fine. This rules out the plan, the credentials, and the endpoint.
What this points to
Beyond the model-ID prefixing already tracked in #359 / fix #360 (we can confirm the dual-entry symptom on 0.10.0: harness inspect valid models contain both zai:glm-5.3-flash and custom:zp:glm-5.3-flash, and the UI picker surfaces the prefixed one as the familiar zp channel), the new signal here is the auth-mode dimension:
- When CodexHost spawns the Hermes engine, the Coding-Plan credential path appears not to be carried into the harness instance (isolated
-I-style home / missing OAuth/plan token inheritance / provider resolution only supporting API-key mode).
- Standalone Hermes resolves the plan login natively, which is why it works there and not under CodexHost.
Request
- Please verify how the Hermes adapter passes provider credentials to the spawned engine, specifically for OAuth / Coding-Plan-type auth vs plain API keys;
- Relatedly, whether the prefixed
custom:<provider>:<model> entries (from Codex-side model_providers) are intended to be usable from the Hermes engine — today they surface in the picker and deterministically fail.
Happy to provide logs, config excerpts (redacted), or run any diagnostic build on this machine.
Environment
Summary (user-verified across multiple runs)
The same machine, same Hermes engine, two auth paths — opposite outcomes:
codexhost delegate start --harness hermes --model <zai:glm-5.3-flash bare ref>→ completed, reply "READY". UI sessions onzai / glm-5.3-flashalso work.zp / glm-5.3-flashin the picker) fail at spawn with the generic "Unable to start this chat" — reproducible every time, zero model output.What this points to
Beyond the model-ID prefixing already tracked in #359 / fix #360 (we can confirm the dual-entry symptom on 0.10.0:
harness inspectvalid models contain bothzai:glm-5.3-flashandcustom:zp:glm-5.3-flash, and the UI picker surfaces the prefixed one as the familiarzpchannel), the new signal here is the auth-mode dimension:-I-style home / missing OAuth/plan token inheritance / provider resolution only supporting API-key mode).Request
custom:<provider>:<model>entries (from Codex-sidemodel_providers) are intended to be usable from the Hermes engine — today they surface in the picker and deterministically fail.Happy to provide logs, config excerpts (redacted), or run any diagnostic build on this machine.