Bug report: Session resume after rate limit loses task intent and continues on wrong context

Open 💬 8 comments Opened Dec 19, 2025 by jroth1111

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug report: Session "resume after rate limit" loses task intent and continues on wrong context

Title

After hitting usage limit, resuming a Codex/agent session often drops latest instructions and continues with unrelated work (task drift + repeated prompts)

Summary

When a long-running Codex/agent session hits a usage limit and is later resumed (same or different account), the assistant frequently fails to continue the last requested task. It instead:

Reverts to earlier context
Repeats previously completed steps/prompts
Performs unrelated work that was never requested

This appears correlated with Context compacted events and/or the transition through the rate-limit boundary.

Environment

Product: Codex/agent session (CLI-style flow with resume semantics)
Model observed in transcript: gpt-5.2-codex xhigh (after resume)
Timeframe: Dec 2025
Workflow: multi-step interactive work; user issues continue after selecting next steps; rate limit interrupts
Thread ID: 019b3469-9795-7b42-be13-705d06d2cbaf

Steps to reproduce

Start a long interactive session with multi-step tasks (planning -> docs -> experiments -> follow-up validation).
Have the assistant create/update documentation or notes files.
Ask the assistant to run targeted experiments and summarize findings.
Ask it to continue with explicit next steps (for example: validate specific comparisons across 2-3 cases, then rework a scheduler logic).
Hit a usage limit (You have hit your usage limit...).
Resume session later (same account or different account) and repeat the last instruction (continue).

Expected result

The assistant resumes exactly from the last instruction:
runs the requested validation across the requested cases,
reworks the logic as requested,
updates the relevant files,
and reports results with continuity.

Actual result

After resuming:

The assistant does not proceed with the requested validation or rework.
It instead performs unrelated work (for example: updates an unrelated spec doc), then restarts earlier prompts, and/or replays previously completed steps.
The flow shows loss of the current task pointer and drift to a different goal.

Evidence

Immediately after the rate limit boundary, the assistant outputs an update to an unrelated doc and restarts earlier prompts, despite those already being completed pre-limit.
The pre-limit state included a clear user instruction to continue with explicit next steps; the post-limit output did not follow those steps.

Impact

Wasted tokens/time: repeats already-finished work and rehashes earlier context.
Incorrect artifacts: may modify the wrong files.
Reliability issue: resume after limit becomes unusable for multi-step workflows without manual restatement.

Severity

High for multi-step engineering workflows. This breaks continuity and can lead to unintended code/doc changes.

Suspected causes

Context compaction drops the active task and last user constraints near the limit boundary.
Resume may rehydrate the wrong summary (or an earlier summary) rather than the most recent local state.
Session identity mismatch when resuming under another account (or changed model) may reduce access to the latest conversation state and/or tool state, amplifying drift.
Loss of ephemeral state (what to do next, which experiments remain) causes the assistant to fall back to generic or earlier instructions.

Workarounds

Write a persistent handoff file before limits (for example: SESSION_HANDOFF.md) including current goal, completed steps, next steps, and exact commands/URLs.
After resume, explicitly instruct: Read SESSION_HANDOFF.md and continue from Next steps.
Prefer resuming with the same session ID and same environment where possible; avoid switching accounts mid-session.

Suggested fix / product improvement

Persist and restore an explicit current task pointer (last user instruction + structured plan) separate from the compressed conversation summary.
On resume, show a brief Resume checkpoint (last task, last artifacts touched, pending steps) and bias execution toward completing pending steps before starting new work.
Detect drift: if the next assistant action edits unrelated files/goals, prompt for confirmation or re-anchor to last instruction.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 7 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#8256
#6950
#7531
#6354

Powered by Codex Action

etraut-openai contributor · 7 months ago

Thanks for the bug report. You mentioned both rate limits and compaction. Of the two, I can explain why you might be seeing this behavior if a compaction occurred, but I don't have any good theories for why it would occur after hitting a rate limit. Are you sure that it's correlated to a rate limit event?

When a rate limit is approaching, codex may suggest that you switch to a smaller/cheaper model to extend your usage. Do you recall switching to a different model, by any chance?

Are you performing manual compactions with /compact, or are you relying on the auto compaction behavior?

jroth1111 · 7 months ago

Thanks for taking the bug report seriously.

I dug up a concrete recent example. It looks like auto-compaction + resume is the proximate cause, with the rate-limit boundary acting as the trigger for the stale snapshot.

Evidence (summarized):

Pre-limit: last instruction was "apply the same secret-handling method across other repos…"
A "Context compacted" event appeared shortly before the limit.
After "You’ve hit your usage limit… resume", the assistant resumed on an earlier task ("document it clearly and how to set it up") and repeated work already done (docs edits, commit/push), skipping the new instruction entirely. That’s task pointer regression, not just a missed step.

Model/compaction details:

I did NOT use /compact manually. Only auto-compaction (system printed "Context compacted").
The resume also switched models (xhigh -> low) and the Codex CLI auto-updated during the boundary (0.75 -> 0.76). I didn’t intentionally switch models.

Limit boundary observation:

I think the usage/rate limit is hit before the context window limit. The rate limit blocks the next request (the current response may finish), while compaction changes the retained state. In my case compaction occurred right before the rate-limit boundary, so the resume appears to rehydrate a stale compacted summary.

Repro suggestion:

Use a ChatGPT Team/Plus account and code in a long session until you hit the rate limit.
Before resuming, copy out the transcript/state so you can compare it after resume.
Then either switch accounts or wait until the rate limit resets and resume the same session.
Compare the transcript immediately before the rate limit with the transcript after resume (especially the last user instruction and pending steps) to see the drift/replay.

So I’m not 100% sure rate-limit alone is causal; the resume seems to rehydrate a stale summary when compaction is involved. Happy to share full transcript/timestamps if helpful.

etraut-openai contributor · 7 months ago

Based on your analysis and clues, I think the rate-limit boundary is _not_ causal. However, it may be correlated because compaction does consume tokens, so if you're close to your rate limit, a compaction event could easily consume all of the remaining usage for that time window.

Thanks for offering to share your session. That would be useful. If you see this happen again, please use the /feedback slash command to upload your session, and post the thread ID here.

AmirTlinov · 6 months ago

This is exactly the kind of problem that motivated #8573.

The core issue: after compaction (triggered by rate limit or context exhaustion), the agent loses the explicit task pointer — it has no structured record of "what was I doing and what's the next step".

The RFC proposes storing a deterministic checkpoint_v1.json that includes:

task: the original user intent (never lost)
plan: current steps with completion status
recentArtifacts: what files were touched (with hashes)

On resume, instead of trying to reconstruct from a lossy "memento" summary, we inject view_v1(checkpoint) which explicitly says "here's your task, here's your plan, here's what you already did".

This would directly prevent the "reverts to earlier context" and "repeats previously completed steps" symptoms you described — the checkpoint knows exactly which steps are done.

vjain419 contributor · 4 months ago

+1 This looks related to #12503. Both describe rate-limit interruptions breaking long-running workflows and causing poor resume/continuation behavior.

gvelesandro · 4 months ago

Your report about resume/compaction losing the active task pointer is exactly the kind of failure story I'm collecting.

I'm researching where real agent workflows break because context, plan state, or workflow history gets dropped. If you're open to it, I'd value one short postmortem from your team. No pitch.

5-minute form: https://www.agentsneedcontext.com/agent-failure-postmortem

yehudareisler · 1 month ago

I saw the same problem in a mobile/remote workflow.

I hit a temporary quota limit for a couple of hours. After quota refreshed, the thread had no clear resume action. When I manually continued in the same thread, it responded to that new message but no longer seemed to retain the prior active task goal.

So in my case this was both a missing resume affordance and a loss of the active goal after quota interruption.