Regression: server-side context compaction interrupts Codex execution and requires manual continuation

What version of Codex CLI is running?

0.135

What subscription do you have?

5.5-pro

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

Title: Regression: server-side context compaction interrupts Codex execution and requires manual continuation

Summary

There appears to be a regression in Codex server-side context compaction.

Previously, Codex could continue executing a long-running coding task for tens of minutes. Server-side context compaction appeared to happen silently, and execution would continue without user intervention.

Recently, after the Codex context compaction latency issue was mitigated, compaction appears to be faster, but a new issue appeared: after server-side compaction succeeds, Codex stops execution and emits a WIP/HANDOFF/BLOCK-style response, requiring the user to manually continue.

This makes automatic context compaction behave like a manual confirmation boundary, which breaks long-running coding workflows.

Expected behavior

When automatic/server-side context compaction is triggered:

RUNNING
→ server-side context compaction
→ compacted context restored
→ continue previous execution frontier automatically

Compaction should be silent from the user's perspective and should not become a stop condition.

Codex should only stop and ask for user input when there is a real reason, such as:

• approval required
• sandbox or permission boundary
• forbidden file/domain risk
• reviewer BLOCK requiring owner decision
• unrecoverable tool/runtime error
• task DELIVER completed

Actual behavior

After server-side compaction, Codex stops and asks for manual continuation even when:

• no approval is required
• no command has failed
• no file was modified
• no forbidden domain was touched
• no reviewer BLOCK occurred
• the next action is clearly executable

Observed transition:

RUNNING
→ server-side context compaction
→ token usage drops
→ Codex emits WIP/HANDOFF/BLOCK-style response
→ WAITING_FOR_USER_CONFIRMATION

Evidence observed

During a long-running Codex coding task:

• Local token usage dropped from approximately 260k to 180k, indicating server-side context compaction completed successfully.
• Immediately after that, Codex stopped and produced a WIP/BLOCK-style response instead of continuing execution.
• The response mentioned a system-level compaction/soft-limit boundary.
• Codex later referred to an internal tool/marker named quota_soft_limit_marker.
• The tool description was reported as something like neutral marker used by relay scheduling.
• This marker is not part of my repository, not part of my local workflow tools, and not part of my project protocol.
• No project files were changed.
• No repository commands were executed.
• No real engineering BLOCK occurred.

This suggests that an internal runtime quota/context marker may be leaking into the model-visible execution state and incorrectly forcing a transition from RUNNING to WAITING_FOR_USER_CONFIRMATION.

Reproduction pattern

1. Start a long-running Codex coding task.
2. Use a structured patch workflow with clear fields such as:

• current_patch
• next_exact_action
• stop_condition
• block_condition
• forbidden-domain list

1. Let Codex continue working until server-side context compaction is triggered.
2. Observe local token usage dropping significantly, for example from around 260k to 180k.
3. Observe that Codex stops and emits a WIP/HANDOFF/BLOCK-style response instead of silently continuing.
4. Manually tell Codex to continue.
5. Codex can continue after manual confirmation, which suggests the task itself was not blocked; only the post-compaction execution state was wrong.

Why this looks like a regression

There was recently a Codex context compaction latency issue. It looks like the latency problem may have been mitigated, because compaction now happens faster.

However, after the mitigation, a new execution-continuity issue appears:

Before:
RUNNING → COMPACTING → RUNNING

Now:
RUNNING → COMPACTING → WAITING_FOR_USER_CONFIRMATION

So this looks like a post-compaction resume-state regression.

Impact

This breaks long-running agentic coding workflows.

Before this behavior change, Codex could work continuously for tens of minutes before responding. Now it may stop every few minutes after compaction and require the user to manually confirm continuation.

This is especially disruptive for workflows that rely on:

• red-test-first development
• patch-level state machines
• reviewer gates
• forbidden-domain checks
• long-running repository refactors
• multi-step coding plans
• autonomous execution until BLOCK or DELIVER

In these workflows, compaction should preserve execution continuity, not interrupt it.

Suggested invariant

Please ensure this invariant holds:

context_compaction_event != user_stop_condition

More specifically:

If automatic/server-side compaction succeeds,
and no approval/sandbox/permission/reviewer/forbidden-domain/block condition exists,
then Codex should restore the previous execution frontier and continue automatically.

Environment

• Product: Codex / Codex CLI / Codex Desktop / ChatGPT Codex
• Plan: ChatGPT Pro
• Model route: GPT-5.5 / Codex model route
• Date observed: [fill in date and timezone]
• Local context settings: [fill in, for example context=400000, output=128000]
• OS: [fill in]
• Codex version: [fill in]
• Session URL / ID if available: [fill in]

Attachments to provide

I can provide:

• screenshot of the WIP/HANDOFF/BLOCK response after compaction
• screenshot/log showing token usage dropping from around 260k to 180k
• the response mentioning quota_soft_limit_marker
• the prompt explicitly instructing Codex not to stop before the patch is completed
• the follow-up showing that Codex continued after manual confirmation

Request

Please investigate whether the recent context compaction latency mitigation changed the post-compaction execution state from RUNNING to WAITING_FOR_USER_CONFIRMATION.

The core issue is not that compaction happens. The issue is that successful server-side compaction now appears to interrupt execution instead of silently resuming it.

What steps can reproduce the bug?

Steps to reproduce

1. Start a long-running Codex coding task in a repository.
2. Use a structured multi-step patch workflow where Codex has a clear current patch, next action, stop condition, and forbidden-domain list.
3. Explicitly instruct Codex not to stop or reply until the patch is completed, unless there is a real blocker such as approval required, sandbox violation, forbidden-domain risk, reviewer BLOCK, or DELIVER.
4. Let Codex work long enough for server-side/automatic context compaction to be triggered.
5. Observe that local token usage drops significantly, for example from around 260k tokens to around 180k tokens, which indicates that server-side context compaction succeeded.
6. Immediately after compaction, Codex stops and emits a WIP/HANDOFF/BLOCK-style response instead of continuing execution.
7. Manually tell Codex to continue.
8. Codex continues normally, which suggests that the task itself was not blocked; the interruption was caused by the post-compaction execution state.

Minimal reproduction prompt

You are working inside a repository.

Complete the current patch before replying to the user.

Do not stop, summarize, or ask for confirmation until the patch is complete.

Compaction is not a stop condition.
After automatic/server-side context compaction, restore EXECUTE/RUNNING state and continue the next action automatically.

Only stop if one of the following happens:
- approval is required
- sandbox or permission boundary is reached
- forbidden files/domains would be touched
- reviewer BLOCK requires user decision
- unrecoverable tool/runtime error occurs
- the patch is completed and ready for DELIVER

Now continue the patch:
1. Run workflow validation.
2. Check forbidden domains.
3. Locate the relevant file.
4. Add a red test first.
5. Implement the minimal fix.
6. Run the required tests/gates.
7. Continue until BLOCK or DELIVER.

Observed behavior

Even with the above instruction, Codex stops shortly after a server-side compaction event and replies with a WIP/BLOCK-style message. In one observed case, it mentioned a system-level compaction or soft-limit boundary and later referred to an internal marker named quota_soft_limit_marker, described as neutral marker used by relay scheduling.

This marker is not part of my repository, not part of my local workflow, and not part of my project tools.

Expected behavior

Server-side context compaction should be silent from the user's perspective. If compaction succeeds and no real approval/block condition exists, Codex should restore the previous execution frontier and continue automatically.

Expected state transition:

RUNNING
→ server-side context compaction
→ compacted context restored
→ RUNNING

Actual observed state transition:

RUNNING
→ server-side context compaction
→ token usage drops
→ WIP/HANDOFF/BLOCK response
→ WAITING_FOR_USER_CONFIRMATION

Impact

This breaks long-running Codex coding workflows. Previously, Codex could continue working for tens of minutes before replying. Now, after compaction, it may stop every few minutes and require manual confirmation, even though the task is safe to continue and no real blocker exists.

This appears to be a post-compaction resume-state regression, not a repository workflow issue.

What is the expected behavior?

_No response_

Additional information

_No response_