hermes - 💡(How to fix) Fix v0.15.0: Codex requests fail HTTP 400 when participant display_name contains non-ASCII (emoji breaks input[].name pattern)

Summary

After upgrading to v0.15.0, Codex API requests now fail with HTTP 400 when any participant in the conversation has a display_name containing non-ASCII characters (specifically emoji, which are common in Discord display names like "Sis 💜", "Ghost 👻", "Banks 💰").

agent.conversation_loop: API call failed (attempt 1/1) error_type=BadRequestError
provider=openai-codex base_url=https://chatgpt.com/backend-api/codex
model=gpt-5.4 summary=HTTP 400: Invalid 'input[7].name': string does not
match pattern. Expected a string that matches the pattern '^[a-zA-Z0-9_-]+$'.

OpenAI's Responses API requires the name field on input items to match ^[a-zA-Z0-9_-]+$. Hermes v0.15.0 passes the Discord message.author.display_name directly as that field, and emoji break the pattern.

Repro

1. Fleet with display_name containing emoji (e.g. "Sis 💜")
2. Send any tool-using prompt that triggers a multi-turn conversation
3. Hermes builds the OpenAI input array including those display names as name fields
4. Codex rejects the entire request with HTTP 400

Environment

• Hermes Agent v0.15.0 (2026.5.28) from PyPI
• Provider: openai-codex / gpt-5.4
• Endpoint: https://chatgpt.com/backend-api/codex
• 13-profile fleet, all bots with emoji in display_name

Comparison to v0.14.0

v0.14.0 didn't pass name fields to Codex (or sanitized them), so this validation never triggered. v0.15.0's stricter request shape exposed the issue.

Suggested fix

Sanitize name before sending to Codex. Either:

import re
def _safe_name(display_name: str) -> str:
    cleaned = re.sub(r"[^a-zA-Z0-9_-]+", "_", display_name).strip("_")
    return cleaned[:64] if cleaned else "user"

...or omit the name field entirely when it would be invalid (it's optional in the Responses API).

Workaround

Currently rolled back to v0.14.0 (which has the older #33237 NoneType bug) because the emoji-display-name issue is non-bypassable from the Discord side — operators legitimately use emoji in bot identities. Local Ollama fallback chain handles the gap.

Cross-ref

• #33237 — Codex NoneType (fixed in v0.15.0, but blocked by THIS new bug for any deployment with emoji display_names)
• #34034 — v0.15.0 broken release (missing plugin.yaml manifests, separate issue)
• #28162 — packaging fix PR

Hoping v0.15.1 (the manifest-fix release) can also include the name sanitization. Otherwise we're stuck on v0.14.0 → local fallback indefinitely.