[BUG] Context condensing triggers even when disabled

[hannesrudolph]

Type

Bug

Problem

Context condensing sometimes triggers even when the automatic option is turned off.

Context

Users who have auto-condense disabled still see a "Context condensed" event during normal use. This appears intermittently and is not easy to reproduce consistently. It may occur when the conversation nears or exceeds the model's limit, where a fallback seems to condense context despite the setting being off. This results in unexpected summarization and changes to the conversation history.

Desired behavior

When auto-condense is disabled, do not perform any automatic condensing. If the context limit is exceeded, use non-summarizing truncation only. If an "emergency condense on overflow" behavior is desired, expose it as a separate setting that can be turned off.

Reproduction (not consistent)

1. Auto-condense disabled in settings
2. Continue a long conversation
3. A "Context condensed" event appears even though the setting is off

Impact

Unexpected summarization can cause loss of details and confusion about why the conversation changed, especially for users who intentionally disable automatic condensing.

[roomote]

I'm exploring a potential fix for the context condensing issue and will open a PR to share progress.

[hannesrudolph]

Hey — I dug into this and found why “Context condensed” can still appear even when auto‑condense is off.

What’s happening

• When the model rejects a request for exceeding the context window, we route through the overflow handler Task.handleContextWindowExceededError(). That handler currently forces summarization by calling truncateConversationIfNeeded() with autoCondenseContext: true and a forced threshold FORCED_CONTEXT_REDUCTION_PERCENT via autoCondenseContextPercent.
• With that flag set, the condense branch in truncateConversationIfNeeded() invokes summarizeConversation(), and we emit the “Context condensed” row via say("condense_context"). That’s exactly the event users are seeing.
• Under normal requests we do respect the setting (see Task.attemptApiRequest(), which reads the user’s state and passes autoCondenseContext through to truncateConversationIfNeeded()). There’s also test coverage ensuring “no summarize when autoCondenseContext is false” sliding-window.spec.ts. So the intermittent reports are coming from the overflow path specifically.

Suggested fix

• Update Task.handleContextWindowExceededError() to respect the user’s setting. Instead of hard‑coding autoCondenseContext: true (and the forced autoCondenseContextPercent):
  • Read autoCondenseContext and autoCondenseContextPercent from state and pass those into truncateConversationIfNeeded().
  • This ensures that when auto‑condense is disabled, we fall back to non‑summarizing sliding‑window truncation only (see the fallback at sliding-window/index.ts). That path returns an empty summary and therefore won’t emit a “condense_context” row.
• Optional UX improvement: add a separate “Emergency condense on overflow” toggle (default ON for backward compatibility) in Context Management near the existing control in ContextManagementSettings.tsx. Overflow logic could be:
  • If ON, keep today’s behavior by forcing summarize (pass autoCondenseContext=true with autoCondenseContextPercent=FORCED_CONTEXT_REDUCTION_PERCENT).
  • If OFF, pass autoCondenseContext=false so we only truncate. This wires similarly to how auto‑condense is stored (see setter pattern in ExtensionStateContext.tsx).

Why this matches the report

• The “sometimes” aspect aligns with only hitting the forced‑condense path when the request actually overflows. Respecting the user setting (or the new overflow toggle) removes unexpected summarization and the “Context condensed” row when auto‑condense is off.

Test ideas

• Simulate overflow with autoCondenseContext=false and assert summarizeConversation() is not called and no “condense_context” message is produced.
• If adding the overflow toggle, verify both branches (emergency=ON condenses; emergency=OFF truncates).

@roomote-agent please make a fix based off this

[roomote]

@hannesrudolph Thank you for the detailed analysis! I've reviewed your findings about the context condensing issue occurring in the overflow handler path. I'll implement the suggested fix to respect the user's autoCondenseContext setting in Task.handleContextWindowExceededError() and explore adding the optional 'Emergency condense on overflow' toggle. Let me start working on this implementation.