fix(codex): pass maxRenderedContextChars to legacy mirrored-history fallback#94595
fix(codex): pass maxRenderedContextChars to legacy mirrored-history fallback#94595xydigit-zt wants to merge 1 commit into
Conversation
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close: the merged current-main replacement at #94093 already includes the useful fix from this PR, adds the missing turn input-limit fitting and stronger continuity tests, and this branch is now conflicting with main. Canonical path: Keep the broader #94093 implementation on main, ship it in the next release, and close this conflicting duplicate branch. So I’m closing this here and keeping the remaining discussion on #94093. Review detailsBest possible solution: Keep the broader #94093 implementation on main, ship it in the next release, and close this conflicting duplicate branch. Do we have a high-confidence way to reproduce the issue? Yes, the original bug is source-reproducible on the PR base and in the linked issue: the legacy continuity calls omitted Is this the best way to solve the issue? No, this PR is no longer the best way to solve the issue. The best current solution is the merged replacement, which preserves this parity fix and also handles Codex turn/start input limits and forced fresh-thread continuity. Security review: Security review cleared: The PR diff only changes Codex runtime projection sizing and tests; it does not add dependencies, workflows, secrets handling, permissions, or package execution surfaces. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 49e6f5a524bc; fix evidence: commit ea76a45917ca, main fix timestamp 2026-06-18T22:33:48Z. |
0a63a46 to
d9ada5d
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
@clawsweeper re-review |
…allback The legacy mirrored-history fallback at run-attempt.ts:1088-1092 was calling projectContextEngineAssemblyForCodex without maxRenderedContextChars, falling back to DEFAULT_RENDERED_CONTEXT_CHARS=24000 instead of deriving a budget-scaled cap from contextTokenBudget. This fix copies the maxRenderedContextChars kwarg from the active-context-engine branch (lines 952-957) into the legacy fallback call site, matching the behavior added in PR openclaw#80761 for issue openclaw#80760. Fixes openclaw#84084
d9ada5d to
4a091cd
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
ClawSweeper applied the proposed close for this PR.
|

Real behavior proof
Behavior or issue addressed: Legacy mirrored-history fallback in
run-attempt.tswas callingprojectContextEngineAssemblyForCodexwithoutmaxRenderedContextChars, causing it to fall back toDEFAULT_RENDERED_CONTEXT_CHARS = 24000instead of deriving a budget-scaled cap fromcontextTokenBudget. This affected both the stale-resume path and the fresh-thread path.Real environment tested: macOS 14.6.1, Node 22, openclaw main @ 967fb8d
Exact steps or command run after this patch:
Evidence after fix:
Both legacy projection paths (fresh-thread at line 906, stale-resume at line 1094) now pass
maxRenderedContextCharsderived fromcontextTokenBudget, matching the active context-engine pattern at line 952.Unit tests (2 new regression tests for #84084):
✓ "uses the runtime token budget for legacy fresh-thread continuity projection (#84084)" — verifies budget cap on fresh-thread path
✓ "uses the runtime token budget for stale-binding continuity projection (#84084)" — verifies budget cap on stale-binding path
Observed result after fix: Default 24,000-char cap becomes a budget-scaled cap (e.g., 1,000,000 chars for 272k token budget). All 107 run-attempt tests pass including the 2 new regression tests.
What was not tested: Live Codex session with mid-session thread rebuild trigger. The code path requires a running Codex OAuth session; the change is structurally identical to the already-merged active context-engine path (PR #80761, lines 952-957).
Out-of-scope follow-ups
None.