HERMES AGENT OAUTH BROKEN - "Error: 'NoneType' object is not iterable"

Same to me

thought I was going crazy when Hermes started throwing this at me. Been chasing my tail trying to solve it
---
⚠️ API call failed (attempt 1/3): TypeError
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
📝 Error: 'NoneType' object is not iterable
⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable
❌ Non-retryable client error (HTTP None). Aborting.
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
💡 This type of error won't be fixed by retrying.

same to me.

I'm using OpenAI OAuth Codex, GPT 5.5 the same setup as you.

The error I'm seeing on Discord is as follows:

⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable

⚠️ 'NoneType' object is not iterable

same here; is this an OpenAI OAuth situation or is it Hermes-driven?

The codex issue is a Hermes Problem
https://github.com/NousResearch/hermes-agent/pull/32890

I just bailed on OpenClaw and configured Hermes. It worked great, for a while. The first time I attempted to use it for something tangible a few hours later, I get hit with those errors.

SSH

⚠️ API call failed (attempt 1/3): TypeError
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
📝 Error: 'NoneType' object is not iterable
⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable
❌ Non-retryable client error (HTTP None). Aborting.
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
💡 This type of error won't be fixed by retrying.
─ ⚕ Hermes ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Error: 'NoneType' object is not iterable

Telegram

⚠️ The model provider failed after retries. I kept raw provider details out of chat; check gateway logs for diagnostics.

⚠️ 'NoneType' object is not iterable

Discord

⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable
⚠️ 'NoneType' object is not iterable

Bump, same

⚠️ API call failed (attempt 1/3): TypeError
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
📝 Error: 'NoneType' object is not iterable
⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable
❌ Non-retryable client error (HTTP None). Aborting.
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
💡 This type of error won't be fixed by retrying.

Same with me

⚠️ API call failed (attempt 1/3): TypeError
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
📝 Error: 'NoneType' object is not iterable
⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable
❌ Non-retryable client error (HTTP None). Aborting.
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
💡 This type of error won't be fixed by retrying.

Same error:
⚠️ API call failed (attempt 1/3): TypeError
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
📝 Error: 'NoneType' object is not iterable
⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable
❌ Non-retryable client error (HTTP None). Aborting.
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
💡 This type of error won't be fixed by retrying.

Same, really frustrating. Been working on a fix since I got home.

This issue has been resolved.
https://github.com/NousResearch/hermes-agent/pull/32963

Confirmed, the update did the trick. Thanks!

updating what? I have updated the agent and re-connected codex but nothing

Same for me

API call failed (attempt 1/3): TypeError
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
📝 Error: 'NoneType' object is not iterable
⚠️ Non-retryable error (HTTP None) — trying fallback...
❌ Non-retryable error (HTTP None): 'NoneType' object is not iterable
❌ Non-retryable client error (HTTP None). Aborting.
🔌 Provider: openai-codex Model: gpt-5.5
🌐 Endpoint: https://chatgpt.com/backend-api/codex
💡 This type of error won't be fixed by retrying.

updating what? I have updated the agent and re-connected codex but nothing

same

have hermes released the fixed version?

Same error

I had gemini look at the issue and it seems to have fixed it:

│ The issue is client-side in the OpenAI SDK itself, which does not defend against response.output being None
│ (which the API returns under certain rate-limit, timeout, or error conditions).
│
│ You can temporarily fix this by patching the following three files in your Python environment:
│
│ 1. openai/lib/_parsing/_responses.py (around line 61):
│ # Change:
│ for output in response.output:
│ # To:
│ for output in (response.output or []):
│
│ 2. openai/types/responses/response.py (around line 315):
│ # Change:
│ for output in self.output:
│ # To:
│ for output in (self.output or []):
│
│ 3. openai/types/responses/parsed_response.py (around line 100):
│ # Change:
│ for output in self.output:
│ # To:
│ for output in (self.output or []):
│
│
│ This prevents the SDK from crashing with a fatal TypeError when the backend returns empty output items.
│ Hopefully, the maintainers can merge a similar defensive guard in the next release!

Hermes Agent NoneType object is not iterable Hotfix Report

Issue Summary

A Hermes Agent using ChatGPT/OpenAI as its model engine was failing during normal conversation.
When a user sent a short or unclear message, for example:

uh?

The agent did not return a normal assistant reply. Instead, it exposed internal system errors back to the user, such as:

Non-retryable error (HTTP None) - trying fallback...

and:

'NoneType' object is not iterable

This made the agent appear broken from the user's side, even though the model itself was still capable of answering.
---

Root Cause

The issue appears to be caused by a streaming response/parsing bug between Hermes Agent and the OpenAI/ChatGPT response flow.
In some cases, the model response is streamed correctly, but the final parsed response object contains:

response.output = None

The code then attempts to loop through response.output as if it were a list:

for output in response.output:

Because response.output is None, Python raises:

'NoneType' object is not iterable

In simple terms, the code is effectively trying to do this:

for item in None:

which is invalid.
The safer behaviour is to treat a missing output as an empty list:

for output in (response.output or []):

---

Why a Normal Docker Update May Not Fix It

The agent may be installed using a platform-managed Docker image.
The standard Docker image may not yet have been rebuilt with the latest Hermes/OpenAI parsing fix. This means that even if a fix exists upstream, redeploying or
restarting the standard image can continue to use the unfixed code.
In other words:

Latest Docker image does not always equal latest source code fix.

There can be a delay between:

1. A fix being merged or released in source code
2. A new Docker image being built
3. A platform-managed image being updated
4. The user's deployed container actually receiving that update

---

Why Replacing the Whole Docker Image May Not Be Ideal

A patched upstream Hermes Agent image may not behave the same as a platform-provided Docker image.
A platform-provided image may have its own:

• Startup process
• Mounted data structure

• Configuration paths
• Environment handling
• API key handling
• Provider settings
• Agent state
• Sessions
• Connected tools

Replacing the whole image can cause Hermes to start as a fresh installation and fail to pick up the existing configuration.
The safer fix is usually to keep the existing working image and patch only the broken OpenAI response parser inside that environment.
---

Final Fix Applied

The working platform-provided Docker image was restored first.
Then the OpenAI SDK parser inside the running container was patched.
The problematic line:

for output in response.output:

was changed to:

for output in (response.output or []):

This prevents Hermes from crashing when response.output is None.
After restarting the container, the agent started responding normally again.
---

Generic Fix Instructions

1. Find the Running Hermes Container

Run:

sudo docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"


Find the Hermes container name, then set it as a variable:
```bash
export HERMES_CONTAINER=<YOUR_HERMES_CONTAINER_NAME>

Example:

export HERMES_CONTAINER=your-hermes-container-name

---

2. Find the Docker Compose Folder

Run:

sudo docker inspect "$HERMES_CONTAINER" --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'

Set it as a variable:

export HERMES_COMPOSE_DIR=<YOUR_COMPOSE_FOLDER>

Example:

export HERMES_COMPOSE_DIR=/path/to/your/hermes/project

---

3. Find and Back Up the Data Mount

Run:

sudo docker inspect "$HERMES_CONTAINER" --format '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

Look for the mount that points to:

/opt/data

Example:

/path/on/host/data -> /opt/data

Back it up before making any changes:

sudo tar -czf ~/hermes-data-backup-$(date +%F-%H%M).tar.gz <HOST_DATA_FOLDER>

Example:

sudo tar -czf ~/hermes-data-backup-$(date +%F-%H%M).tar.gz /path/on/host/data

---

4. Patch the OpenAI Parser Inside the Running Container

Run this from the host server:

sudo docker exec -i "$HERMES_CONTAINER" bash <<'BASH'
set -e
python3 - <<'PY'
from pathlib import Path
candidates = []
try:
 import openai
 candidates.append(Path(openai.__file__).parent / "lib" / "_parsing" / "_responses.py")
except Exception as e:
 print(f"Could not import openai directly: {e}")
for base in [Path("/opt/data/python-packages"), Path("/usr/local/lib"), Path("/opt/hermes")]:
 if base.exists():
 candidates.extend(base.rglob("openai/lib/_parsing/_responses.py"))
seen = []
for p in candidates:
 if p.exists() and p not in seen:
seen.append(p)
if not seen:
 raise SystemExit("Could not find openai/lib/_parsing/_responses.py")
for p in seen:
 print(f"Checking: {p}")
 src = p.read_text()
 old = "for output in response.output:"
 new = "for output in (response.output or []):"
 backup = p.with_name(p.name + ".bak")
 if not backup.exists():
 backup.write_text(src)
 print(f"Backup created: {backup}")
 if new in src:
 print(f"Already patched: {p}")
 elif old in src:
 p.write_text(src.replace(old, new, 1))
 print(f"Patched: {p}")
 else:
 print(f"Target line not found in: {p}")
PY
BASH

---

5. Restart Hermes

Go to the Docker Compose folder:

cd "$HERMES_COMPOSE_DIR"

Restart the service:

sudo docker compose restart

Or, if you know the exact service name:

sudo docker compose restart <SERVICE_NAME>

Check the logs:

sudo docker compose logs -f --tail=100

---

6. Test the Agent

Send a simple message through the connected channel:

hello

Then test the original failure case:

uh?

The agent should now reply normally instead of sending:

'NoneType' object is not iterable

---

Making the Fix Persistent

The patch above modifies the currently running container.
If the container is recreated from the original image, the patch may be lost.
To preserve the patched version, commit the patched container to a local Docker image:

sudo docker commit "$HERMES_CONTAINER" hermes-agent:hotfix-null-output

Then update the Docker Compose YAML to use:

image: hermes-agent:hotfix-null-output

pull_policy: never

Then redeploy.
This keeps the existing working setup but prevents Docker from replacing the patched image with the old unfixed remote image.
---

Important Notes

Do not force-apply GitHub patches directly to a live Hermes installation unless the patch applies cleanly.
Do not replace a platform-managed Hermes image with the upstream image unless you are prepared to manually recreate:

• Volumes
• Environment variables
• Entrypoints
• Configuration paths
• API keys
• Provider settings
• Agent state
• Connected tools

The safest approach is:

1. Back up data
2. Keep the working image
3. Patch only the broken parser
4. Restart
5. Test the agent
6. Commit the patched container to a local image if the fix works

---

Long-Term Recommendation

This should be treated as a temporary hotfix.
The correct long-term solution is for the platform-provided Hermes Docker image to be rebuilt with the official upstream fix included.
Once the official Docker image includes the fix, users should return to the official image and remove the local hotfix image.

> updating what? I have updated the agent and re-connected codex but nothing same have hermes released the fixed version?

The hermes has fixed the problem.
https://github.com/NousResearch/hermes-agent/pull/32963

Just run uv pip install --upgrade hermes-agent to make sure your Hermes is in sync with the main branch.

you can run hermes --version to check how many commits behind the main branch you are.

Worked for me LOL

Running hermes update solved it

hermes update did solved it but i still get these warning :
No first byte from provider in 45s (codex stream, model: gpt-5.3-codex). Reconnecting.
anyone know whats the problem?

Running hermes update solved it

Yes , update it"s fix

Running hermes update solved it

this fixed my issue

I ran into the same error.

Running hermes update fixed it for me as well.

Docker Fix: Patch Hermes OpenAI SDK Response Parser

Use this fix when the Hermes Docker container fails because the OpenAI SDK tries to iterate over response.output when it is None.

What this patch changes

It updates the Hermes container’s OpenAI SDK parser from:

for output in response.output:

to:

for output in (response.output or []):

This prevents a crash when response.output is missing or None.

---

Patch Command

Run this on the host machine where the hermes Docker container is running:

docker exec -it hermes sh -lc '
SDK_FILE="/opt/hermes/.venv/lib/python3.13/site-packages/openai/lib/_parsing/_responses.py"

grep -n "for output in .*response.output" "$SDK_FILE" || true

python3 - <<PY
from pathlib import Path

path = Path("/opt/hermes/.venv/lib/python3.13/site-packages/openai/lib/_parsing/_responses.py")
text = path.read_text()

old = "for output in response.output:"
new = "for output in (response.output or []):"

if new in text:
    print("SDK patch already applied")
elif old in text:
    path.write_text(text.replace(old, new, 1))
    print("SDK patch applied")
else:
    print("SDK patch failed: target line not found")
    raise SystemExit(1)
PY

grep -n "for output in .*response.output" "$SDK_FILE" || true
'

docker restart hermes

---

Expected Success Output

You should see something like:

61:    for output in response.output:
SDK patch applied
61:    for output in (response.output or []):
hermes

If you see:

SDK patch already applied

then the fix is already in place.

---

Verify Hermes Logs

After restarting the container, check the logs:

docker logs --tail=100 hermes

For live logs:

docker logs -f hermes

I had gemini look at the issue and it seems to have fixed it: │ The issue is client-side in the OpenAI SDK itself, which does not defend against response.output being None │ (which the API returns under certain rate-limit, timeout, or error conditions). │ │ You can temporarily fix this by patching the following three files in your Python environment: │ │ 1. openai/lib/_parsing/_responses.py (around line 61): │ # Change: │ for output in response.output: │ # To: │ for output in (response.output or []): │ │ 2. openai/types/responses/response.py (around line 315): │ # Change: │ for output in self.output: │ # To: │ for output in (self.output or []): │ │ 3. openai/types/responses/parsed_response.py (around line 100): │ # Change: │ for output in self.output: │ # To: │ for output in (self.output or []): │ │ │ This prevents the SDK from crashing with a fatal TypeError when the backend returns empty output items. │ Hopefully, the maintainers can merge a similar defensive guard in the next release!

This unblocked me ! Thanks mate.

edit:
a small thing: "hermes update" didn't work for me, showed as there is nothing to update. Now updates have succeeded and stuff seems working OK.

Running hermes update worked for me, I had to also restart my gateway for the changes to take effect

\> posts _hermes_ issue to _codex_ repo without trying to isolate where the issue is coming form
\> determines this is, in fact, a _hermes_ issue
\> everyone keeps dumping useless walls of text "fixing the issue"
\> RIP public github issues

hermes update

confirmed, working.

use "hermes update" will fix all

Same issue here on the Hostinger Hermes image (ghcr.io/hostinger/hvps-hermes-agent:latest). Re-pulling the image shows it's already up to date, so the update doesn't fix it.
Root cause isn't in Hermes — it's the OpenAI SDK's parse_response() iterating over response.output when the Codex backend now returns it as null. Patching the SDK directly fixed it for me:

docker exec -it hermes-agent-jd9b-hermes-gateway-1 bash -c \
'sed -i "s/for output in response.output:/for output in (response.output or []):/" \
$(python3 -c "import openai; print(openai.__file__.rsplit(\"/\",1)[0])")/lib/_parsing/_responses.py'

(Patches .../openai/lib/_parsing/_responses.py:61.) Restart the gateway afterwards. Note it's inside the container, so it has to be re-applied after any image re-pull / container recreation until the SDK is fixed upstream.