Codex app-server runtime loses thread context across turns (gateway starts a fresh thread each message)

[gmkseta]

What happened?

Under the codex_app_server runtime (openai_runtime: codex_app_server), multi-turn conversations on the gateway lose the Codex thread's working context between messages.

The runtime is documented to keep "one Codex thread per Hermes session" (agent/transports/codex_app_server_session.py), but the gateway builds a fresh AIAgent per inbound message, so agent._codex_session is None at the start of every turn and ensure_started() issues a brand-new thread/start. Because a Codex thread's working context (files read, command output, plan state, long-running task state) lives inside the thread — turn/start only sends the latest user message — every follow-up message hands the model an empty thread and silently loses all prior work.

Steps to reproduce

1. Enable openai_runtime: codex_app_server.
2. On a gateway platform (Discord/Telegram), message 1: "read file X".
3. Message 2: "what did you just read?"

Observed: the model has no memory of message 1 (a fresh thread/start ran). Agent logs show distinct codex thread ids per message within one session.

Expected

The session resumes the same Codex thread across turns (codex app-server exposes thread/resume {threadId}, which reloads the persisted rollout from disk), preserving context until the conversation is explicitly reset (/new).

Environment

• Codex CLI 0.133.0
• Runtime: codex_app_server, gateway (Discord)

[teknium1]

This is an automated hermes-sweeper review: the reported per-message fresh-thread behavior is already fixed on current main.

• gateway/run.py:18155-18256 reuses the cached AIAgent for the same gateway session instead of constructing one for every inbound message (introduced by 342096b4b, feat(gateway): cache AIAgent per session for prompt caching).
• agent/codex_runtime.py:339-342 keeps one CodexAppServerSession on that agent and reuses it across turns.
• agent/transports/codex_app_server_session.py:240-298 returns the existing thread id once started; its lifecycle test verifies only one thread/start request.

The linked #41905 remains relevant for durable thread/resume after a gateway restart or cache eviction, but the issue's stated normal gateway follow-up regression—creating a fresh Codex thread for every message—is implemented on main.

[Shaance]

Confirmed this remains reproducible on current main in the restart/cache-eviction case covered by #41905, with an additional concrete trigger: gateway hygiene evicts the live app-server session even when native compaction is skipped/no-op.

Environment:

Hermes Agent v0.18.2 (2026.7.7.2)
commit 42bd4368aef12be890a74b749ae04d009c0a4412
hermes version status: Up to date
macOS / Darwin 25.5.0 arm64
Python 3.11.14
OpenAI SDK 2.24.0
provider: openai-codex
model: gpt-5.6-sol
runtime: codex_app_server
gateway: Telegram

Redacted log sequence:

Session hygiene: 190 messages, ~231,228 tokens — auto-compressing
codex app-server compaction skipped: mode=native
Gateway hygiene compression ... did not rotate or compact in place
Session hygiene: compressed 190 -> 190 msgs
OpenAI client closed (cache_evict)
conversation turn: ... history=189
Skipping Hermes preflight compression for codex app-server (mode=native)
codex app-server thread started: id=<new thread>

The next answer had lost the prior conversational context even though the durable Hermes transcript was intact and the turn logged history=189.

Current source still shows the lifecycle gap:

• agent/transports/codex_app_server_session.py:240-298 calls thread/start when a new in-memory session is created.
• agent/codex_runtime.py:399-414 passes only user_message into that new session.
• agent/codex_runtime.py:535-555 returns codex_thread_id, but current main does not durably rehydrate it.
• gateway/run.py:11814-11821 unconditionally evicts the cached agent after hygiene, including after the native app-server compaction no-op.

Switching model.openai_runtime to auto is an effective workaround because Hermes then rebuilds model input from its durable transcript. I have applied that locally for now.

This is strong current-main confirmation that #41905's durable thread/resume work is still needed. It would also be worth making the hygiene eviction runtime-aware so a skipped/no-op native compaction does not discard a healthy live app-server thread unnecessarily.

I ran hermes debug share --local; I am omitting the full dump because recent logs contain private chat content, but can provide more narrowly redacted excerpts if useful.