openclaw - 💡(How to fix) Fix [Bug]: Codex app-server frequently restarts native threads when owner-only tool availability flips [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

A single long-lived OpenClaw session using agentRuntime.id = "codex" repeatedly starts new Codex app-server native threads when the dynamic tool catalog changes only because per-turn owner-only tool availability changes.

Steps to reproduce

Observed 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 alternates between a 74-tool owner catalog and a 71-tool downgraded catalog. The catalog diff is exactly:

cron
gateway
nodes

These are owner-only tools.

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 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 Codex app-server runtime, a new native thread is not just a harmless internal refresh. It loses Codex native thread continuity. OpenClaw still has its own session transcript, and context-engine may inject assembled context into the next prompt, but the Codex app-server thread state is reset.

In practice this causes:

• repeated startup/bootstrap behavior,
• repeated explicit reads of startup files,
• worse prompt cache locality,
• loss of native thread continuity while the user is still in the same OpenClaw session,
• noisy and expensive repeated work.

The visible symptom is that the agent repeatedly calls read tools for startup files such as:

• SOUL.md
• USER.md
• MEMORY.md
• daily memory files
• relevant docs/bootstrap files

OpenClaw version

2026.4.29

Operating system

Linux x86_64, Ubuntu kernel 5.15.0-164-generic; Node.js v22.22.0

Install method

npm global install ([email protected])

Model

gpt-5.5

Provider / routing chain

Feishu DM -> OpenClaw agent runtime agentRuntime.id = "codex" -> Codex app-server runtime -> gpt-5.5

Trajectory rows for the affected Codex app-server runs report:

provider: openai
modelId: gpt-5.5
modelApi: openai-responses

The important runtime detail is that this is the Codex app-server harness path, not the traditional OpenClaw native PI runner.

Additional provider/model setup details

The affected session is a Feishu DM routed to the main OpenClaw agent with agentRuntime.id = "codex". Redacted session key shape:

agent:main:feishu:direct:<redacted-user-id>

Logs, screenshots, and evidence

All times below are local time. This is the same OpenClaw session and the same Feishu DM.

00:14 thread 019de978... toolCount=71  -> new thread, full startup file read
00:15 thread 019de979... toolCount=74  -> new thread, full startup file read
00:20 thread 019de97e... toolCount=71  -> new thread, full startup file read
00:24 thread 019de97e... toolCount=71  -> same thread, no full startup read
00:31 thread 019de988... toolCount=74  -> new thread, full startup file read
00:36 thread 019de988... toolCount=74  -> same thread, no full startup read
00:39 thread 019de988... toolCount=74  -> same thread, no full startup read
00:55 thread 019de99d... toolCount=71  -> new thread, full startup file read
01:05 thread 019de99d... toolCount=71  -> same thread

The pattern is very strong:

• when toolCount changes, Codex starts a new native thread;
• when toolCount stays the same, Codex resumes the existing native thread;
• each new thread is followed by full startup-style reads.

Relevant code path:

• src/auto-reply/reply/get-reply-run.ts can temporarily downgrade ownership when drained system events include untrusted lines.
• src/agents/tool-policy.ts filters owner-only tools for non-owner turns.
• extensions/codex/src/app-server/run-attempt.ts builds dynamic tools for the current turn.
• extensions/codex/src/app-server/thread-lifecycle.ts fingerprints the full dynamic tool catalog and clears the binding when it changes.

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 at least four times in roughly 40 minutes as the tool catalog alternated between 71 and 74 tools.

Consequence: repeated startup-style reads, degraded prompt cache locality, extra model/tool work, and behavior that looks like the agent repeatedly starts fresh.

Additional information

Owner-only filtering itself appears to be intentional and should not be treated as the primary bug.

OpenClaw correctly filters owner-only tools when the current turn is not authorized as owner. This is a security feature. The problematic behavior is that Codex app-server treats this temporary per-turn availability change as native-thread incompatibility and starts a new native thread.

This should not be diagnosed as a bootstrap cache bug. #72406 refreshed bootstrap snapshots so long-lived sessions can see workspace bootstrap/context file changes. That may make startup context behavior more visible, but it is not the root cause of the native thread churn described here. The thread churn is driven by Codex app-server dynamic tool fingerprint changes.

A narrow fix that only ignores 74 -> 71 owner-only tool removals is not enough, because 71 -> 74 would still restart the thread.

A proper fix likely needs one of these approaches:

1. Allow Codex app-server dynamic tools to be updated on thread/resume or turn/start, so per-turn tool availability can change without starting a new native thread.
2. Keep a stable thread-level tool schema and enforce per-turn authorization in the OpenClaw dynamic tool bridge. Unauthorized owner-only calls should return a tool error for that turn.
3. Split tool schema identity from per-turn availability/authorization. Only real schema contract changes should invalidate the Codex native thread.

The key invariant should be:

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