Codex Desktop: high-context threads cannot compact or recover; need out-of-band compaction or fresh thread on same worktree

What variant of Codex are you using?

Codex Desktop App

What issue are you seeing?

In long-running Codex Desktop worktree sessions, context can grow so high that automatic/manual context compaction no longer provides a usable recovery path.

The user-visible failure mode is effectively:

• the thread is at very high context usage;
• Codex needs to compact before it can continue;
• compaction either fails or cannot be triggered/recovered cleanly once the context is already too large;
• the only reliable workaround is to abandon the thread and start over;
• but there is no first-class way to start a zero-context/new-transcript thread attached to the same existing Codex-managed worktree.

This combines two product gaps:

1. Compaction should be able to recover an oversized/high-context thread, either by running out-of-band against stored history or by triggering earlier with sufficient reserved budget.
2. If compaction cannot recover, Codex should offer a safe fallback that preserves the current filesystem/git/index state, such as "New thread here" / "fresh context on this worktree".

Today, for a worktree-backed thread, the available options are awkward:

• Fork keeps the old conversation context, so it does not solve context pollution or context-window exhaustion.
• New worktree creates a different checkout, so it does not preserve the exact current worktree state.
• Opening the managed worktree by path is a workaround, but it is not discoverable or first-class in the UI.

Why this matters

Long-running coding tasks often accumulate exactly the context needed to understand the work, but also enough token load to make the thread fragile. When compaction fails at high context, the user is forced to choose between losing thread continuity and losing the exact worktree state.

For real development work, the desired recovery path is:

same cwd + same files + same git/index state + empty or compacted transcript

The product currently makes that path hard to discover.

Expected behavior

Codex should provide one or more of:

• automatic compaction before the active request reaches an unrecoverable size;
• /compact or automatic compaction that runs out-of-band against stored history, so it can recover even when the active thread is too large to fit in the model context;
• recursive/chunked compaction for oversized histories;
• a clear failure recovery UI when compaction cannot complete;
• a first-class "New thread here" / "Use existing worktree with fresh context" action from a worktree-backed thread;
• a way to clear/reset transcript context while staying attached to the same worktree.

Actual behavior

Once the thread is too high-context, compaction may fail or become unavailable as a recovery mechanism. The user is then told to start a new thread, but the new-thread UI does not let them pick the existing Codex-managed worktree as the execution target.

Related issues found before filing

This appears related to, but not fully covered by, several existing issues:

• #29319: automatic context compaction fails at 258k / 258k and aborts with a context-window error.
• #29302: /compact cannot recover a resumed long thread when loaded history is already too large.
• #23589: /compact reports success and then fails with context_length_exceeded.
• #24876: auto-compacting triggers too late or fails on 5.5 extra high.
• #19829: request for a command to clear context in the current session/worktree.
• #22316: request to select existing worktrees, which would provide an important recovery path after compaction failure.
• #29967: proposal for speculative pre-turn compaction.

This issue is specifically about the combined high-context recovery workflow: if compaction fails or cannot run, Codex should still let the user continue from the same worktree/files/git state with fresh or safely compacted context.

Additional information

Exact app version and feedback bundle were not captured at the time of filing. The behavior was observed in Codex Desktop on macOS while using a worktree-backed local repository workflow.