swarm-master/swarm-common/obsidian-vault/will/will-shared-zap/Atlas/Reports/2026-05-25-codex-hermes-proxy-experiment-audit.md

type, project, status, owner, created, updated, source, tags

type	project	status	owner	created	updated	source	tags
agent-audit-event	Atlas Capability Upgrade Program	accepted	Atlas	2026-05-25	2026-05-25	Telegram request: prototype Hermes local OpenAI-compatible proxy with one external coding tool	atlas audit agent-event hermes proxy codex

Agent Audit Event — Codex + Hermes local proxy experiment

Summary

• When: 2026-05-25
• Actor: Atlas / Hermes default Telegram session
• Trigger: User request from daily Hermes + AI research brief follow-up
• Outcome: partial
• One-line result: Codex can be pointed at a local OpenAI-compatible base URL, but the current Hermes proxy is not ready for a complete Codex-through-Hermes run without a logged-in proxy upstream and/or endpoint compatibility work.

Runtime

• Model: gpt-5.5
• Provider: OpenAI Codex backend for Hermes session
• Profile/session: default Hermes Telegram session
• Tools used: terminal, file/search/read/write, process
• MCP servers / external services: Hermes local proxy CLI; Codex CLI 0.129.0; local loopback capture server

Data touched

• Local paths: /home/will/.hermes/hermes_cli/proxy/*, /home/will/.codex/config.toml, temporary files under /tmp
• Remote systems: none for the prototype request path; no real upstream completion was performed
• Secrets/PII exposure: Codex used its own local auth while probing a local capture endpoint; do not use raw request capture servers for future authenticated probes unless auth is disabled with a temporary CODEX_HOME.
• Writes/side effects: created and removed/terminated a temporary local HTTP capture process; wrote this audit note

Cost and latency

• Approx. cost: no successful model completion through the proxy; cost unknown / likely none for the failed local capture run
• Latency / runtime: quick local smoke, under a few minutes
• Notable performance notes: Codex retried /v1/responses several times after websocket upgrade failures before falling back to POST.

Evidence

• Hermes proxy status: hermes proxy status showed nous and xai adapters available but not logged in on this profile.
• Hermes proxy allowed paths:
  • Nous: /chat/completions, /completions, /embeddings, /models
  • xAI: /chat/completions, /completions, /embeddings, /models, /responses
• Codex endpoint behavior: with openai_base_url="http://127.0.0.1:8765/v1", Codex 0.129.0 probed GET /v1/models?client_version=0.129.0, then attempted websocket GET /v1/responses, then POST /v1/responses.
• Compatibility finding:
  • Codex is not a good first full-success target for the Nous proxy path because Codex uses Responses API, while the Nous proxy adapter only forwards chat/completions-style paths.
  • Codex may be plausible through the xAI proxy adapter because xAI allows /responses, but the adapter was not logged in and websocket behavior still needs verification.
  • Aider is likely the better first full-success target for Nous because it uses OpenAI-compatible chat completions, but it is not installed on this machine.
• Follow-up: For a clean full prototype, either:
  1. authenticate hermes proxy --provider xai and retry Codex with a temporary CODEX_HOME, or
  2. install/use Aider against hermes proxy --provider nous once Nous Portal proxy auth is available.