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

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

• #23257
• #24014
• #23589
• #24089
• #23263

Powered by Codex Action

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

Issue Summary

• Issue: https://github.com/openai/codex/issues/24100
• Type: Enhancement - proactive handoff and rescue workflow
• Labels: enhancement, context, app, session
• Impact: Remote Codex sessions that become unrecoverable lose context and work
• Competition: 1 comment, 0 PRs (low competition)

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;

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.

This is the exact failure mode that makes remote compaction unrecoverable: the rollout grew large because old turns still carry embedded image data URLs from pasted screenshots, so the compaction request itself — which has to send that history to the model — exceeds the context window, and now the thread can't even produce its own handoff summary. The thread is stuck in a state where the only thing that could shrink it requires it to already be small.

The way out is to stop asking the stuck thread to rescue itself: extract the durable transcript locally, strip the no-longer-needed image payloads, and fork a clean session that carries the project context without the media weight. That's a local, read-only-first operation — the remote model never has to process the bloated history.

Full disclosure: I maintain codex-rescue (https://github.com/shleder/codex-rescue). codex-rescue storage profiles how much of the rollout is embedded image data vs actual transcript, and salvage extracts the durable history into a clean fork read-only-first, dropping the redundant image payloads so the forked session fits the context window again. verify checks the salvaged session before you continue on it. This is precisely the proactive-handoff workflow this issue is asking for, done locally instead of through the stuck remote compaction path.