Fixes #85975.

Summary

• Preserve context-engine thread_bootstrap Codex native thread bindings through the startup token/byte transcript guard so large bootstrap turns do not force cold thread/start on every later turn.
• Keep native reuse bounded by the existing context-engine compatibility checks: engine/policy, projection epoch/fingerprint, dynamic tool fingerprint, and compaction-driven binding invalidation.
• Add regression coverage for token- and byte-oversized bootstrap transcripts resuming the warmed native thread while avoiding context-engine assembled-history replay.

Why this matters

This is not about the model's maximum context window. CODEX_APP_SERVER_NATIVE_THREAD_MAX_TOKENS = 70_000 is a local OpenClaw/Codex app-server active-thread reuse guard. It can rotate a native thread much earlier than the model's real context limit.

For example, the current repo metadata around gpt-5.5 includes much larger limits than 70k: Copilot fallback metadata uses a 400_000 context window and related legacy Codex metadata recognizes a 272_000 prompt-token shape with 128_000 max output. So a 70k native-thread guard can invalidate the warm thread while the selected model still has plenty of context headroom.

That distinction matters because thread_bootstrap is the token-efficiency contract:

• First turn: OpenClaw assembles expensive context and injects it into a new Codex native thread.
• Later turns, best case: OpenClaw resumes the same native thread and does not replay the context-engine assembled history; the bootstrapped context is already inside the native thread. Other workspace/bootstrap surfaces may still contribute turn instructions or prompt context separately.
• Broken case: OpenClaw clears the native thread binding before it checks the context-engine bootstrap binding, so every turn cold-starts and re-injects/reprojects the large bootstrap payload.

Even when provider-side prompt caching helps with identical prefixes, the cold path still loses Codex native-thread reuse and creates avoidable gateway/app-server work: context assembly, prompt rendering, tool/app setup, rollout scanning, and a fresh native thread startup.

Thread/cache flow

flowchart TD
  A[New Discord/user turn] --> B[OpenClaw loads saved Codex native thread binding]
  B --> C{Saved binding has contextEngine.projection.mode = thread_bootstrap?}
  C -- yes --> D[This PR: defer startup token/byte guard]
  D --> E[Context engine assembles current view]
  E --> F{Engine, policy, epoch, fingerprint, and tools still match?}
  F -- yes --> G[thread/resume warm native Codex thread]
  G --> H[turn/start avoids context-engine history replay]
  F -- no --> I[Clear stale binding and start fresh thread]
  C -- no --> J[Legacy/workspace-bootstrap path still uses 70k startup guard]
  J --> K{nativeTokens or sessionTokens >= 70k?}
  K -- yes --> L[Clear binding; thread/start cold path]
  K -- no --> G

10-turn scenario

Illustrative numbers, not exact billing math:

• A context-engine bootstrap payload renders to 90k tokens.
• Each later user turn adds a small 2k-token prompt/delta.
• Desired thread_bootstrap behavior over 10 turns: one large context-engine bootstrap, then 9 warm resumes. Replayed bootstrap pressure is roughly 90k + 9 * 2k = 108k plus model-visible continuation state and any separate workspace/turn-scoped context surfaces.
• Broken startup-guard behavior: the first 90k turn records native usage over the 70k guard. Each later startup clears the binding, starts a fresh native thread, and replays/rebuilds the large bootstrap again. That can become roughly 10 * 90k = 900k of repeated bootstrap pressure before counting deltas.

The important part is the shape, not the exact multiplier: once the native thread is rotated every turn, the system stops amortizing the bootstrap.

What this PR fixes

Current startup order was:

1. Read saved Codex app-server thread binding.
2. Apply byte/token native transcript guard.
3. Only later ask the context engine whether the saved thread_bootstrap binding is still compatible.

That means an 86k-token bootstrap rollout could delete a still-valid thread_bootstrap binding before the code reached the compatibility check that would have allowed reuse.

This PR changes only that ordering for bindings that already declare contextEngine.projection.mode === "thread_bootstrap" and when a current active context engine can re-evaluate the saved binding:

• If the saved binding is a context-engine thread_bootstrap and the current run has an active context engine, startup defers the proactive byte/token guard.
• startOrResumeThread still clears the binding if the current context-engine policy/projection/tool binding is incompatible.
• If the saved binding is stale and no context engine is active for the current turn, the startup size guard still clears the oversized native thread so prompt construction projects mirrored history into the fresh thread.
• Non-bootstrap native sessions still use the existing byte/token startup guard.

So the PR fixes a concrete correctness bug: compatible context-engine bootstrap threads should be allowed to reach the existing compatibility gate instead of being preemptively deleted by a generic native transcript-size guard.

What this PR does not fully solve

A tester reported that after locally merging this PR, their Discord channel was still slow and logged:

nativeTokens=116268, max 70000
codex app-server native transcript exceeded active token limit; starting a fresh thread

They also observed the cold path re-injecting/truncating large bootstrap files such as AGENTS.md, USER.md, and MEMORY.md.

Based on the code, that exact warning after this PR means the startup exemption did not apply for that session. The most likely explanations are:

• the saved binding has no contextEngine.projection.mode = "thread_bootstrap" marker, so it is on the legacy/workspace-bootstrap path;
• the context engine is returning per_turn, no valid epoch, or no projection binding;
• the projection epoch/fingerprint, policy fingerprint, dynamic tool fingerprint, MCP/app config, or environment selection changes every turn, so lifecycle compatibility still starts a fresh thread;
• the local test build did not include the latest PR head; or
• the session is a non-context-engine native session, where the old 70k guard intentionally still applies.

In other words: this PR removes one real source of churn, but it is not the full architecture fix for all oversized Discord/Codex sessions. It makes the safe thread_bootstrap path behave like its contract says. Sessions that never enter or never retain that path can still cold-start every turn.

Follow-up architecture

The broader architecture should probably move toward:

• treating context/bootstrap ownership as the lifecycle authority: rotate on semantic epoch/fingerprint/tool/config changes, not only on a hard-coded 70k native usage number;
• making the native reuse guard model/config aware instead of a fixed local threshold that can be lower than common bootstrap payloads;
• bringing workspace bootstrap files under an explicit cache/binding contract, or at least avoiding full AGENTS.md / USER.md / MEMORY.md reinjection when the same files are unchanged;
• logging enough provenance to diagnose every rotation: binding mode, projection epoch/fingerprint, projection decision reason, token source (last_token_usage vs total_token_usage vs sessions.json), and which bootstrap files dominate rendered context;
• distinguishing "provider/model context overflow" from "OpenClaw native warm-thread reuse guard" in warnings and status output.

Useful logs to compare on a slow channel after this PR:

codex app-server deferring native transcript size guard for context-engine thread bootstrap
codex app-server context-engine projection decision
codex app-server wrote context-engine thread binding
codex app-server context-engine binding changed; starting a new thread
codex app-server native transcript exceeded active token limit; starting a fresh thread

Real behavior proof

• Behavior or issue addressed: Codex app-server startup binding rotation should not clear a still-compatible context-engine thread_bootstrap native thread just because the bootstrap rollout exceeded the native token or byte guard.
• Real environment tested: local patched OpenClaw checkout at /Volumes/LEXAR/repos/worktrees/openclaw-codex-native-thread-reuse, using Lexar scratch under /Volumes/LEXAR/Codex/openclaw-codex-native-thread-proof-20260524-151049.
• Exact steps or command run after this patch: ran a live node --import tsx --input-type=module probe against the patched production testing.rotateOversizedCodexAppServerStartupBinding export. The probe wrote real Codex app-server binding, sessions.json, and rollout files for token-oversized and byte-oversized thread_bootstrap cases, then read the saved binding back from disk.
• Evidence after fix: terminal output from the local OpenClaw checkout:

/Volumes/LEXAR/repos/worktrees/openclaw-codex-native-thread-reuse
REAL_BEHAVIOR_PROOF case=token-over-86k returnedThreadId=thread-bootstrapped savedThreadId=thread-bootstrapped projection=thread_bootstrap
REAL_BEHAVIOR_PROOF case=byte-over-2k returnedThreadId=thread-bootstrapped savedThreadId=thread-bootstrapped projection=thread_bootstrap
REAL_BEHAVIOR_PROOF proofRoot=/Volumes/LEXAR/Codex/openclaw-codex-native-thread-proof-20260524-151049

• Observed result after fix: both oversized native transcript cases returned and persisted the warmed thread-bootstrapped binding with projection=thread_bootstrap; the startup guard did not clear the binding.
• What was not tested: no live Discord channel or real Codex app-server network session was exercised from this PR branch; full broad validation is left to GitHub CI.

Verification

• Behavior addressed: a saved thread_bootstrap binding whose native rollout reports 86k latest tokens now uses thread/resume and does not replay assembled bootstrap context into turn/start.
• Real environment tested: local Lexar OpenClaw worktree at /Volumes/LEXAR/repos/worktrees/openclaw-codex-native-thread-reuse.
• Exact commands run after this patch:

pnpm exec oxfmt --check --threads=1 extensions/codex/src/app-server/run-attempt.ts extensions/codex/src/app-server/run-attempt.context-engine.test.ts extensions/codex/src/app-server/run-attempt.test.ts
pnpm tsgo:extensions:test
OPENCLAW_VITEST_MAX_WORKERS=1 node scripts/run-vitest.mjs extensions/codex/src/app-server/run-attempt.context-engine.test.ts --run
OPENCLAW_VITEST_MAX_WORKERS=1 node scripts/run-vitest.mjs extensions/codex/src/app-server/run-attempt.test.ts --run -t "starts a fresh Codex thread before resume when the native rollout is over budget|uses current rollout token usage before cumulative usage|clears native rollouts at the configured byte limit"
git diff --check

• Evidence after fix:
  • pnpm tsgo:extensions:test: passed.
  • run-attempt.context-engine.test.ts: 20/20 passed, including the stale/no-active context-engine regression.
  • targeted run-attempt.test.ts native guard slice: 3 passed, 215 skipped.
  • formatting and whitespace checks passed.
• Pi/runtime risk review: parallel adversarial review found this change limited to Codex app-server startup binding rotation; Pi embedded-runner/shared compaction semantics are not changed.

Full repository-wide suites were intentionally left to GitHub CI per the local-resource policy.