openclaw - 💡(How to fix) Fix [Bug]: Codex app-server churns native threads when owner-only tool availability flips

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

This is a refreshed report for #76179. I am closing the old issue only because it has gone stale in triage; the underlying behavior still appears unresolved on current main.

A long-lived OpenClaw session using agentRuntime.id = "codex" can still start a new Codex app-server native thread when the only dynamic-tool catalog difference is temporary per-turn owner-only tool availability.

The observed catalog diff is exactly these owner-only tools:

cron
gateway
nodes

Current main status

Checked against current main at 7fbca96 on 2026-05-26.

The old issue is still source-reproducible in the same shape:

• Codex app-server thread lifecycle fingerprints the dynamic tool catalog and treats non-empty fingerprint differences as incompatible.
• Codex app-server run attempts pass the current turn's dynamic tool specs into thread lifecycle.
• Owner-only tool policy still changes availability based on per-turn senderIsOwner / downgraded trust state.
• When the owner-only tools are filtered out for a downgraded turn, the native thread binding can be cleared and a new Codex native thread starts.

Steps to reproduce

Observed originally in a Feishu DM session configured to use the Codex app-server runtime:

1. Run OpenClaw with an agent configured with agentRuntime.id = "codex".
2. Use a long-lived Feishu DM session as an owner, so owner-only tools are normally available.
3. Let a turn drain untrusted system events, for example exec completion/failure events.
4. Send more messages in the same Feishu DM session.
5. Observe Codex app-server native thread IDs and dynamic tool counts in trajectory logs.

The same OpenClaw session alternated between a 74-tool owner catalog and a 71-tool downgraded catalog.

Expected behavior

Temporary per-turn authorization changes should not force a new Codex native thread.

The current turn must still enforce authorization correctly. If the turn is downgraded, owner-only tools must fail closed and must not execute. But the Codex native thread should remain continuous across turns in the same OpenClaw session.

Actual behavior

Codex app-server treats temporary owner-only tool availability changes as dynamic tool schema incompatibility, clears the thread binding, and starts a new native thread.

For the Codex app-server runtime, this is visible to users because the agent loses Codex native thread continuity while OpenClaw is still in the same session. In practice this causes:

• repeated startup/bootstrap behavior
• repeated reads of startup files such as SOUL.md, USER.md, MEMORY.md, daily memory files, and bootstrap docs
• worse prompt cache locality
• noisy and expensive repeated work

Prior evidence and discussion carried forward

Old issue: #76179

Prior ClawSweeper review kept #76179 open and summarized the problem as source-reproducible: alternate the same Codex app-server session between owner and downgraded turns, toolBridge.specs changes by cron, gateway, and nodes, and current main treats the fingerprint as incompatible and starts thread/start.

Important security point from that review: any fix that stabilizes the Codex tool schema must keep unauthorized cron, gateway, and nodes execution fail-closed.

Prior discussion also asked for attention from the Codex app-server lifecycle side. Related people mentioned by the old review/discussion included steipete, jalehman, gumadeiras, and sercada; this is context, not an ownership assignment.

Related PRs

• #83369 (fix(codex): keep owner-only tool schema stable) is the narrow active fix path and currently has green checks.
• #83367 (Fix Codex runtime hook and session churn) also references the old issue but is broader.

Impact and severity

Affected: channel sessions using agentRuntime.id = "codex", observed in Feishu DM.

Severity: High for long-running Codex runtime sessions. The user remains in the same OpenClaw session, but Codex native thread continuity is repeatedly lost.

Frequency: High in the observed session. The native thread restarted multiple times as the tool catalog alternated between 71 and 74 tools.

Suggested fix direction

Separate Codex thread schema compatibility from per-turn owner authorization.

A good fix should either keep a stable thread-level schema while enforcing per-turn authorization in the dynamic tool bridge, or otherwise allow per-turn tool availability changes without rotating the native thread. The key invariant should be:

Tool schema compatibility may require a new native thread; temporary per-turn permission changes should not.