Selective active-context editing ("Exclude from context") for long-running threads

Open 💬 3 comments Opened Jul 17, 2026 by willerhehehe
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex App (also applicable to CLI and IDE Extension)

What feature would you like to see?

Summary

I would like Codex to support selective active-context editing for long-running threads.

This is different from deleting an entire thread or deleting chat history for privacy purposes. The goal is to let users inspect and selectively exclude specific messages, turns, or context blocks from the context sent to the model in future requests.

Possible names include:

  • Exclude from context
  • Forget this block
  • Context editor
  • Modular context
  • Fluid context

Problem

During a long-running coding task, a single incorrect assumption, misleading sentence, outdated requirement, or irrelevant tool result can bias many later responses.

Once I identify the problematic context, my current options are:

  1. Add another instruction telling Codex to ignore it, which may not reliably override the earlier context.
  2. Start a new thread and manually reconstruct the valid context.
  3. Wait for compaction and hope the problematic information is not preserved.

None of these directly fixes the source of the misunderstanding.

Requested behavior

Allow users to:

  • Inspect the context currently active for the thread.
  • Select one or more messages or context blocks.
  • Mark them as Excluded from future context.
  • Restore excluded blocks with Undo/Include.
  • See an estimated token reduction before applying the change.
  • Distinguish between deleting transcript history and excluding content from active model context.
  • Edit or regenerate the compacted summary if excluded information has already been incorporated into it.
  • Optionally fork the thread from the sanitized context instead of mutating the original thread.

For tool calls, Codex could treat a tool call and its corresponding result as one dependency-aware block, preventing invalid partial histories.

Example

A long task contains an early message saying:

Assume the service always returns schema A.

Later, runtime evidence proves that the deployed service returns schema B.

Even after correcting the assumption, Codex may continue reasoning from schema A because it remains in the conversation history or compacted summary.

I want to select the original assumption and choose:

Exclude from active context

Future turns should then be constructed without that assumption, while the original transcript may remain visible for auditing.

Why this matters

This would:

  • Recover long-running tasks from context pollution.
  • Reduce repeated corrective prompting.
  • Make model behavior easier to debug.
  • Potentially reduce future context/token usage.
  • Preserve useful thread history without forcing users to restart.
  • Give users explicit control over what Codex currently "knows".

Additional information

Related issues:

  • #21347 — individual message deletion
  • #20251 / #13018 — deleting threads and local session data
  • #11325 — manual context compaction
  • #21468 — visible and prompt-guided compaction

The key distinction is that this request concerns the effective context sent to the model, not only deletion of stored chat history. A reversible Exclude from context action would also be safer than destructive transcript deletion.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32863

Powered by Codex Action

willerhehehe · 1 month ago

Thanks for flagging #32863. I reviewed it and believe these issues are related, but not duplicates.

#32863 reports a specific bug where stale conversation state repeatedly resurfaces after correction.

This issue requests a user-facing context-management capability: inspecting the effective context and selectively excluding, restoring, or forking from particular messages or dependency-aware context blocks. It would help users recover from cases like #32863, but it is also useful for outdated requirements, incorrect assumptions, irrelevant tool output, and other forms of context pollution even when no replay bug occurs.

The distinction is therefore:

  • #32863: investigate and fix unintended stale-state behavior.
  • #33769: provide explicit user control over the context sent to the model.

I suggest keeping this open as a separate feature request while treating #32863 as a related motivating example.

willerhehehe · 1 month ago

Another important motivation is inference efficiency.

Today, correcting a misleading context item usually requires adding more instructions. This increases the context length while leaving the original misleading content in place, forcing the model to resolve competing instructions on every subsequent turn.

Selective context exclusion would be subtractive rather than additive: future requests could contain fewer input tokens and less irrelevant material, potentially reducing context-processing compute, latency, and infrastructure cost.

It would also prevent repeated corrective prompts from further polluting the thread and later compaction summaries.

In short, this is not only a UX feature. It could serve as a user-controlled context-pruning mechanism: remove invalid context instead of continuously adding more context to counteract it.