Skip to content

Codex Desktop: proactive handoff and rescue workflow for unrecoverable remote compaction failures #24100

Open
Open
Codex Desktop: proactive handoff and rescue workflow for unrecoverable remote compaction failures#24100
Labels
appIssues related to the Codex desktop appcontextIssues related to context management (including compaction)enhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@Longtime76
Longtime76
opened on May 22, 2026

Summary

A long-running Codex Desktop project thread became unusable after remote compaction started failing, even for tiny prompts such as "are you there?". The error was:

{
  "error": {
    "message": "Your input exceeds the context window of this model. Please adjust your input and try again.",
    "type": "invalid_request_error",
    "param": "input",
    "code": "context_length_exceeded"
  }
}

This was especially painful because the stuck thread contained substantial project context. Once compaction failed, the thread could not produce its own handoff summary.

Environment

  • Product: Codex Desktop
  • Platform: Windows
  • Model in thread metadata: gpt-5.5, xhigh reasoning
  • Local thread metadata showed Codex CLI/app metadata around 0.118.0-alpha.2, but the user had recently updated Codex before the failure
  • Thread type: long-running project thread with many pasted screenshots/images over time

What happened

The local rollout had grown very large because older prompts and tool outputs still contained embedded image data URLs from pasted screenshots. Those images were no longer needed for the active work, but they remained in the local thread history. When Codex attempted remote compaction, the compaction request itself appeared to exceed the model context window, leaving the thread unable to answer even a minimal prompt.

Recovery approach that worked

A second helper Codex thread was able to repair the broken thread locally:

  1. Identified the local rollout for the stuck thread.
  2. Created a durable handoff summary as a fallback.
  3. Backed up the original rollout file.
  4. Replaced embedded image payloads with lightweight placeholders while preserving message/tool structure.
  5. Waited until Codex was fully closed so the app would not rewrite cached state.
  6. Replaced the original rollout path in place with the repaired, image-stripped rollout.
  7. Restarted Codex and opened the original thread.

After this, the original thread responded successfully and appeared intact.

Observed local numbers from this case:

  • Rollout reduced from about 611 MB to about 52.7 MB.
  • Embedded data:image payloads reduced to zero.
  • JSON parse errors after repair: zero.
  • Thread became usable again after restart.

Why this matters

The most valuable Codex threads are often the ones most likely to become long, media-heavy, and hard to replace. If compaction fails after a thread has crossed the point where it can answer, the user cannot ask that same thread to summarize itself or create a handoff.

Feature requests

  1. Proactively detect when a thread is approaching compaction failure risk and create a durable handoff before it becomes unusable.
  2. Add a built-in rescue workflow for stuck sessions, especially one that can strip stale pasted images or oversized tool payloads while preserving text context.
  3. When remote compaction fails because the compaction request itself is too large, explain that clearly and offer recovery options: create handoff, strip media payloads, fork a repaired thread, or archive large assets.
  4. Provide a user-visible continuity/export mechanism for long-running project threads that does not depend on the current thread still being able to answer.
  5. Consider a helper-thread pattern as an official workflow: another Codex session can inspect, summarize, and repair the local history of a stuck session under user control.

Related issues

This seems related to prior compaction/context reports such as:

The additional contribution here is the recovery pattern: a helper Codex thread was able to back up and surgically reduce the local history, after which the original thread was recoverable.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    contextIssues related to context management (including compaction)
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 22, 2026

  2. github-actions commented on May 22, 2026

    @github-actions
    github-actionsbot
    on May 22, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. jshaofa-ui commented on May 23, 2026

    @jshaofa-ui
    jshaofa-ui
    on May 23, 2026

    openai/codex #24100: Proactive Handoff and Rescue Workflow for Unrecoverable Remote Connections

    Issue Summary

    Root Cause Analysis

    1. Remote Session Failure Modes

    Codex Desktop remote sessions can become unrecoverable due to:

    • Network disconnection: Intermittent or permanent network loss between client and remote agent
    • Resource exhaustion: Remote agent runs out of memory, disk space, or hits timeout limits
    • Process crash: Remote agent process crashes without graceful shutdown
    • State corruption: Session state becomes inconsistent after partial operations

    2. Current Behavior (Problem)

    Remote Session Lifecycle:
├── Connected → Normal operation
├── Disconnected → ❌ No automatic recovery
│   ├── Session state lost
│   ├── Context window truncated
│   ├── In-progress work discarded
│   └── User must manually restart
└── Unrecoverable → ❌ Total context loss
    ├── No handoff to local agent
    ├── No state preservation
    └── No rescue workflow

    3. Missing Components

    • Health monitoring: No proactive detection of degrading connection quality
    • State checkpointing: No periodic state snapshots for recovery
    • Handoff protocol: No mechanism to transfer session to another agent
    • Rescue workflow: No automated recovery process for failed sessions

    Fix Approach

    Component 1: Connection Health Monitoring

    interface ConnectionHealth {
  latency: number;
  packetLoss: number;
  lastHeartbeat: number;
  quality: 'healthy' | 'degraded' | 'critical';
}

class ConnectionMonitor {
  private healthHistory: ConnectionHealth[] = [];
  private degradationCallbacks: ((health: ConnectionHealth) => void)[] = [];
  
  async monitor(session: RemoteSession): Promise<void> {
    const interval = setInterval(async () => {
      const health = await this.measureHealth(session);
      this.healthHistory.push(health);
      
      // Keep last 60 measurements (5 minutes at 5s intervals)
      if (this.healthHistory.length > 60) {
        this.healthHistory.shift();
      }
      
      // Detect degradation trends
      if (this.isDegradationTrend(health)) {
        this.notifyDegradation(health);
      }
      
      // Detect critical failure
      if (health.quality === 'critical') {
        await this.triggerRescueWorkflow(session, health);
      }
    }, 5000);
  }
  
  private isDegradationTrend(current: ConnectionHealth): boolean {
    if (this.healthHistory.length < 5) return false;

  4. ooiuuii commented on Jun 15, 2026

    @ooiuuii
    ooiuuii
    on Jun 15, 2026

    Adding another user-impact data point for the handoff/rescue side of this issue.

    I had a long-running Codex Desktop thread that contained substantial working context and prior GitHub/project workflow decisions. By the time it was diagnosed, the thread was close to the effective context window, around 232k / 258k, had accumulated large diagnostic/tool outputs, and no active local subprocess explained the stall. The practical advice was to stop using that old thread and continue from a short-context helper thread.

    The painful part is exactly what this issue describes: once the original thread is already degraded, it is risky to ask that same thread to summarize itself or produce a clean handoff. A helper thread can inspect the situation and reconstruct enough continuity, but that is currently an improvised workflow rather than a supported recovery path.

    A built-in rescue flow would have been the right product behavior:

    • detect that the current thread is near the context limit and has no live local subprocess/progress;
    • create a bounded handoff summary from recent durable state, without replaying huge tool outputs;
    • fork a short-context continuation thread with explicit "what was preserved / what was dropped";
    • keep the old thread readable but mark it as degraded or unsafe for more active work;
    • avoid implying that local workspace migration, such as moving a repo out of OneDrive, repairs the already degraded long-context thread.

    This variant was not necessarily an image-payload compaction failure like the original report, but the user impact is the same: the most valuable thread became the least safe place to ask for its own handoff.

    Related narrower diagnostic-boundary issue: #28345.

  5. 3no-mark commented on Sep 14, 2026

    @3no-mark
    3no-mark
    on Sep 14, 2026

    I hit this error when Codex tried to compact a long-running thread:

    Error running remote compact task: Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.

    The current request fails, and I cannot ask the thread to prepare a handoff before moving to a new one. “Start a new thread” leaves me without a reliable record of the work, decisions, and next steps held in the old thread.

    Please provide a Prepare handoff recovery action that remains available after compaction fails. It should produce a copyable summary of the thread’s goal, decisions, work completed, outstanding work, and next steps, without requiring the failed thread to complete another normal request. If possible, offer to start a new thread with that handoff attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appcontextIssues related to context management (including compaction)enhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions