Summary
Some Hermes Responses API paths still maintain their own chat-to-Responses conversion logic. When a path replays history containing tool results, it can send raw chat-style messages with role=tool inside input[].
Problem
The OpenAI Responses API does not accept role=tool in input items. Tool results must be encoded as function_call_output items with a valid call_id.
This causes hard failures on Responses-compatible providers with errors like:
Invalid value: 'tool'. Supported values are: 'assistant', 'system', 'developer', and 'user'.\n```\n\n## Root Cause\nHermes had more than one message conversion path for Responses requests. The main agent already converted tool history correctly, but auxiliary Codex-backed paths still had a separate adapter that replayed messages directly and could leak `role=tool` into the request payload.\n\n## Expected Behavior\nAll Responses API paths should use one shared conversion layer so that:\n- assistant tool calls become `function_call` items\n- tool results become `function_call_output` items\n- no Responses request ever includes raw `role=tool` input items\n\n## Scope\nThis should be fixed centrally so future Responses-capable paths cannot drift apart again.\n
Summary
Some Hermes Responses API paths still maintain their own chat-to-Responses conversion logic. When a path replays history containing tool results, it can send raw chat-style messages with
role=toolinsideinput[].Problem
The OpenAI Responses API does not accept
role=toolin input items. Tool results must be encoded asfunction_call_outputitems with a validcall_id.This causes hard failures on Responses-compatible providers with errors like: