This does not look like Hermes failing to find MEMORY.md. The debug dump shows built-in memory is active, and your screenshot from the direct Codex path shows Hermes can read /home/user/.hermes/memories/USER.md and /home/user/.hermes/memories/MEMORY.md.
The difference is the localhost route:
custom (cx/gpt-5.5-xhigh) through http://localhost:20128/v1/
So the next thing to test is whether omniroute is passing tool schemas/tool calls correctly.
While using the omniroute model, run these two prompts exactly:
Use the read_file tool to read /home/user/.hermes/memories/USER.md and /home/user/.hermes/memories/MEMORY.md before answering. Then tell me the first heading or first sentence from each file.
Then:
Use the skills_list tool and show me the first 5 available skills.
If the omniroute route answers without calling read_file or skills_list, then this is not a MEMORY.md issue. It means the omniroute/custom provider path is not behaving like a working Hermes tool-calling model.
If direct Codex calls those tools correctly but omniroute does not, please paste the tool activity from both runs. That gives us the useful comparison:
direct Codex: tool calls work
omniroute/custom: tool calls missing or malformed
At that point the likely fix is on the omniroute/custom-provider side: it needs to pass OpenAI-compatible tools/tool_calls through cleanly, and the model route needs to support tool calling. If omniroute does return proper tool calls but Hermes still ignores them, then we can look for a Hermes adapter bug.