Been useful so far in Discord and M365 email. The best pattern I’ve found is ���research first, learn later”. Gather context in-thread/email, review it, then only save the skill once I say it’s ready.
Biggest improvement idea would be a built-in review/staging flow for `/learn` so messy source material doesn’t turn into permanent skills too early.
@cursor_ai Composer 2.5 is not respecting Bun projects. In repos with bun.lock and Bun scripts, it still suggests npx, npm, pnpm, etc. GPT-5.5 consistently uses bun/bunx correctly in the same project. Looks like Composer’s package-manager detection/context handling might need some work.
@cursor composer-2.5 for the win… be sure to add “Fix Auxiliary Title with this as well” and you’ll be back up with codex - temporarily…
The actual Codex issue was two-part:
1. The Codex provider config was missing the Responses API mode.
For Codex OAuth against the ChatGPT Codex backend, the model config needs:
model:
provider: openai-codex
default: gpt-5.5
base_url: https://t.co/zbmBeqpJSo
api_mode: codex_responses
The important missing line was:
api_mode: codex_responses
Without that, Hermes can call the wrong response path/parse mode for Codex and fail even though the provider/model/base URL look correct.
2. Hermes also needed a patch for the Codex stream parser failure.
The live failure looked like:
'NoneType' object is not iterable
What was happening:
- The Codex backend was successfully streaming usable assistant text.
- Then the OpenAI SDK/Hermes stream parser failed while handling the terminal response.completed/final response shape because output could be missing/None.
- So the turn failed after useful streamed content had already arrived.
The patch needed in Hermes is in the Codex runtime path:
agent/codex_runtime.py
Patch behavior:
- collect streamed output_text.delta frames and output items as they arrive;
- if get_final_response() raises TypeError like 'NoneType' object is not iterable, synthesize a completed response from the already-collected stream data instead of failing the turn;
- also treat final_response.output is None the same as an empty output list and repair it from collected stream data;
- apply the same empty/None output repair to the create-stream fallback path.
Regression tests should cover:
- final response parser raises TypeError after text deltas were streamed;
- stream iterator raises TypeError after text deltas were streamed;
- final response output is None or empty but stream data exists.
After patching, verify with:
hermes chat -q 'Reply with exactly: GPT55_CODEX_OK' --provider openai-codex -m gpt-5.5 --quiet
Expected output:
GPT55_CODEX_OK
Then verify the default config path:
hermes chat -q 'Reply with exactly: DEFAULT_GPT55_CODEX_OK' --quiet
Expected output:
DEFAULT_GPT55_CODEX_OK
Fallback intent:
- Primary: openai-codex / gpt-5.5 / codex_responses
- Fallback 1 if configured and authenticated: xai-oauth / grok-4.3
- Fallback 2: openai-api / gpt-5.5