maxActiveTranscriptTokens: "120k", // optional Codex native thread token reuse guard

- `maxActiveTranscriptTokens`: optional Codex app-server native-thread token reuse guard (`number` or strings like `"120k"`). When unset, OpenClaw uses Codex's reported model context window with a 300000-token fallback recovery fuse. Set a positive value to override that fuse, or `0` to disable only this token guard while preserving byte limits and semantic binding invalidation.

These bootstrap bytes are not the same thing as the native reuse guard. The

active-token guard is a warm-thread reuse threshold over the persisted/native

Codex transcript and mirrored session totals; it is not simply "bootstrap size".

When unset, OpenClaw uses Codex's reported model context window with a

300000-token fallback recovery fuse. Operators can set `maxActiveTranscriptTokens`

to a lower threshold when legacy native threads should rotate earlier.

The token-efficient context-engine path is `thread_bootstrap`. When the saved

Codex binding still matches the active context-engine id, policy fingerprint,

projection epoch/fingerprint, and dynamic-tool surface, OpenClaw treats the

large bootstrap/projection payload as already present in the native thread and

logs `thread-bootstrap-semantic-reuse` instead of reprojecting it every turn.

Successful context-engine-owned compaction preserves that binding when the

projection mode remains `thread_bootstrap`: same-file compaction leaves it in

place, and successor-transcript rollover copies it to the successor before

clearing the archived original. If those identities change, OpenClaw starts a

fresh Codex thread and reprojects context once for the new epoch. This keeps

long-running agents fast without pretending a stale bootstrap or stale

context-engine projection is still valid.

If context-engine overflow recovery rotates a transcript before a turn starts,

OpenClaw preserves compatible `thread_bootstrap` bindings when their semantic

identity still matches the projected context. Legacy, ownerless, and

non-bootstrap bindings are abandoned so the next turn can rehydrate a fresh

thread from engine-managed context.

Codex harness latency can come from three different pressure points. They look

similar in logs, but they have different fixes.

| Pressure point | Owner | What it means |

| --------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

| Model or app-server context limit | Codex app-server | Codex accepted a native thread or turn and then rejected, compacted, or failed because the real model request could not fit. |

| OpenClaw assembly precheck | OpenClaw | OpenClaw's rendered turn prompt, developer instructions, context-engine projection, media, and reserves are too large before the turn is submitted to app-server. |

| Native-thread reuse rotation | OpenClaw + Codex | OpenClaw has a saved Codex thread binding, but the persisted/native transcript is over the configured warm-thread reuse guard or the binding identity no longer matches. |

The native-thread reuse guard is not the model context window. When unset,

OpenClaw uses Codex's reported model context window, with a 300000-token

fallback recovery fuse when Codex has not reported one. It is a proactive

threshold for deciding whether an existing native Codex thread is still a good

warm resume candidate. Setting `maxActiveTranscriptTokens` to `120k` preserves

an 86000 token native rollout on models with smaller reported windows, while

setting it to `50k` rotates a 60000 token binding. Setting the token guard to

`0` disables only proactive token rotation; byte guards and semantic binding

checks can still rotate.

For context-engine `thread_bootstrap`, the efficient path is a matching

context-engine id, policy fingerprint, projection epoch, projection

fingerprint, and dynamic-tool surface. In that case OpenClaw logs

`thread-bootstrap-semantic-reuse` and skips the proactive token and byte guards,

because the large projection was already bootstrapped into that Codex thread.

Successful context-engine-owned compaction preserves that binding when the

projection remains `thread_bootstrap`. If compaction keeps the same session

file, the binding stays in place. If compaction rolls over to a successor

session file, OpenClaw copies the binding to the successor and clears the

archived original so the next turn can resume the warm Codex thread. Legacy,

ownerless, or non-bootstrap bindings are still invalidated by compaction.

When any semantic identity changes, OpenClaw starts a fresh native thread and

emits `codex.native_thread.lifecycle` with a rotation reason such as

`projection-mismatch`, `context-engine-binding-mismatch`,

`dynamic-tools-mismatch`, `mcp-config-mismatch`,

`environment-selection-mismatch`, `native-tool-surface-disabled`,

`plugin-app-config-mismatch`, `auth-profile-mismatch`, `missing-thread-binding`,

`app-server-rejected-thread`, `native-token-guard`, or `native-byte-guard`.

Compaction itself emits either `context-engine-compaction-preserved-binding` or

`context-engine-compaction-invalidated-binding` so the outcome is visible even

when no fresh thread is started immediately.

The trusted lifecycle diagnostic includes counts, hashed comparison

fingerprints, and basename session-file labels for rollover, but not raw prompt

text, bootstrap file contents, tool arguments, local absolute paths, or secrets.

Its companion log entry is intentionally lower-cardinality and omits scoped

thread/session ids and fingerprints. Use the trusted event to answer whether a

slow Codex session is

rebuilding context because the warm native thread exceeded a guard, because

OpenClaw assembled too much prompt/context, or because Codex itself rejected the

native thread or turn.