Bug Description

When Hermes Agent is deployed through the gateway with a custom OpenAI-compatible provider and model gpt-5.4, normal user messages can fail with a Responses API 400:

HTTP 400: Invalid 'input[n].name': empty string

This still reproduces after:

• running hermes update
• confirmed gateway restart
• running /reset repeatedly

This does not look like a stale-session-only problem. The failing index varies across attempts (input[3], [4], [5], [6], [7], [9], [18], [19]), which suggests Hermes is generating or replaying a malformed Responses input item with an empty function_call.name.

The issue was observed in Weixin gateway usage. I am redacting account identifiers, chat identifiers, filesystem paths, and the custom relay hostname for privacy.

This report supersedes #11378, which used the wrong local machine environment details.

Steps to Reproduce

1. Configure Hermes with a custom OpenAI-compatible provider / relay (hostname redacted)
2. Select model gpt-5.4
3. Run the messaging gateway
4. Confirm hermes update completed and the gateway restarted
5. Run /reset
6. Send a simple plain-text message in Weixin
7. Hermes may return a 400 instead of answering

A concrete conversation pattern seen in logs:

• a first question can succeed
• a short follow-up message that depends on prior context can fail immediately with Invalid 'input[n].name'
• asking the full question again in one turn can succeed

Expected Behavior

A fresh session after /reset should accept normal user messages and either answer normally or fail with a provider/tool error that does not corrupt subsequent turns.

Actual Behavior

Hermes returns errors like:

Non-retryable error (HTTP 400): HTTP 400: Invalid 'input[4].name': empty string. Expected a string with minimum length 1, but got an empty string instead.

The index is not stable. Logs show input[3], [4], [5], [6], [7], [9], [18], and [19] across different sessions.

After the failure, Hermes logs lines such as:

• Skipping transcript persistence for failed request in session ... to prevent session growth loop
• Pre-reset memory flush completed for session ...

But the problem still reproduces in later turns and even after gateway restart.

Affected Component

Configuration (config.yaml, .env, hermes setup), Agent Core (conversation loop, context compression, memory), Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

No response

Debug Report

Redacted local debug summary (sensitive identifiers removed):

- Hermes version: `0.10.0 (2026.4.16) [764536b6]`
- OS: `Darwin 25.1.0 x86_64`
- Python: `3.11.5`
- OpenAI SDK: `2.31.0`
- Profile: `default`
- Model: `gpt-5.4`
- Provider: `custom`
- Gateway: loaded via `launchd`
- Enabled platforms: `feishu, weixin`
- Custom endpoint hostname: redacted for privacy

I can provide a more complete redacted log excerpt if needed, but I do not want to post private identifiers publicly.

Operating System

Darwin 25.1.0 x86_64

Python Version

3.11.5

Hermes Version

0.10.0 (2026.4.16) [764536b6]

Additional Logs / Traceback (optional)

Representative redacted excerpts:


ERROR root: Non-retryable client error: Error code: 400 - {'error': {'message': "Invalid 'input[4].name': empty string. Expected a string with minimum length 1, but got an empty string instead.", 'type': 'invalid_request_error', 'param': 'input[4].name', 'code': 'empty_string'}}

INFO gateway.run: Skipping transcript persistence for failed request in session ... to prevent session growth loop.

INFO gateway.run: Pre-reset memory flush completed for session ...


The same class of error appears repeatedly on Apr 16-17 with multiple input indexes, including `input[3]`, `[4]`, `[5]`, `[6]`, `[7]`, `[9]`, `[18]`, and `[19]`.

Logs also confirm that `hermes update` triggered a gateway restart and that the error still reproduced after the restart.

Root Cause Analysis (optional)

High-probability diagnosis: Hermes is serializing or replaying an invalid Responses API item for custom GPT-5 gateway sessions, most likely a function_call item whose name becomes an empty string.

The evidence points away from a Weixin transport bug and toward the custom + gpt-5.4 + Responses path, especially because:

• the request reaches the provider and fails server-side with schema validation
• the failing array index moves around
• multi-turn follow-up messages are more likely to trigger the problem than fully self-contained one-turn prompts
• /reset and full gateway restart do not reliably eliminate it

Proposed Fix (optional)

Likely fixes:

1. Do not force custom GPT-5 providers onto the Responses path unless the endpoint fully supports OpenAI Responses semantics
2. Add strict validation before sending Responses input items and drop malformed function_call items whose name is empty
3. Add debug logging around Responses payload construction / replay so the malformed item can be identified without exposing user content

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR