After context summarization, the agent loses active Skills and tool-usage knowledge (causes disruptive tool/permission failures)

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Chat / Composer (Agent mode)

Describe the Bug

After the agent’s conversation context is summarized (the long-session, server-side summarization that compacts history), the agent appears to lose operative context that was active before the summarization — in two related ways:

  1. Active Skills are dropped and not reloaded. Skills the agent had read and was actively following earlier in the session stop being in effect after summarization; the agent falls back to metadata-only awareness of them and no longer applies their procedures.
  2. Procedural tool-usage knowledge degrades. The agent seems to forget how to correctly drive its own tools/MCP — including which values to pass to tool parameters it had been using successfully just before the summarization.

Setup. Agent (Composer) running with Auto-Run set to Allowlist (with Sandbox) — i.e. commands run in the sandbox by default, and network beyond the allowlist requires the agent to request elevated access.

Concrete example from a real session. A shell command needed network access beyond the sandbox allowlist. The correct recovery is to re-run with the Shell tool’s permission escalation (required_permissions: ["full_network"]), and the agent had used this correctly earlier in the session. After a summarization event, when a similar command hit the sandbox, the agent instead:

  • retried the command with no required_permissions (failed the same way),
  • then reached for an unrelated approval mechanism,
  • then tried required_permissions: ["all"], which did not grant access in that attempt (the command still ran restricted),
  • and only recovered after re-deriving that ["full_network"] was the value that actually works.

That produced a disruptive loop of several identical failures — the signature of lost procedural context, not a one-off mistake.

Hypothesis. Summarization evicts the in-context Skills and the internalized “how to use the tools / MCP” knowledge (e.g. the correct network-access value), and that eviction is what creates the disruption. Adding an explicit skill-reload step after summarization noticeably mitigates it — which supports the theory that the loss lives in the summarization → context-rebuild path rather than in the tools themselves.

Impact. Wasted turns and confusing behavior immediately after summarization, exactly when long agent sessions are most valuable. In the worst case it can lead to repeated or unsafe actions right after the context is compacted.

Suggested fixes.

  • After summarization, re-inject / reload any Skills that were active (or at least their operative instructions) instead of demoting them to metadata-only.
  • Preserve (or deterministically re-derive) tool-usage invariants — parameter names/values the agent had already used successfully — across the summarization boundary.
  • Consider a post-summarization self-check that reconciles active Skills and known tool state before the agent continues working.

Steps to Reproduce

  1. Start an Agent (Composer) session; have it read and follow one or more Skills, and use tools that require escalated parameters (e.g. a sandboxed shell command re-run with required_permissions).
  2. Continue the session long enough (or leave it idle) to trigger context summarization.
  3. After summarization, ask the agent to perform an action of the same class as before (another command needing network beyond the allowlist, or a step governed by a previously-loaded Skill).
  4. Observe: the agent no longer applies the previously-loaded Skill automatically, and/or fumbles tool parameters it had used correctly before — retrying failing variants.

Expected Behavior

After summarization the agent should retain, or transparently reload, the operative context it needs to keep working: previously-active Skills should stay in effect, and procedural tool-usage knowledge (correct parameter values it had already used) should survive summarization so the agent doesn’t regress into failing retry loops.

Backend references (for triage)

In case it helps correlate with server-side logs (all from the same session, which underwent a summarization event and then showed the behaviour above):

  • Session / composer ID: 24e7eb62-3e46-4efe-bde9-2a33e7e469db
  • Request ID at the failure moment (mid sandbox / required_permissions fumble): 2ab0649f-4802-49c7-b1d6-1330a55eea5b (2026-07-01 08:17:37 UTC)
  • Nearby request IDs in the same disrupted window: 38b21c7c-576d-454a-aabf-f58623fd5c32 (08:03 UTC), 587afb44-84e5-4faa-9238-5b887c843986 (08:22 UTC)
  • Related “An unexpected error occurred” seen in a concurrent session (possibly the same context-loss root cause): Request ID 899e7a6c-6316-492c-af9b-220c0a77c5d7

Operating System

MacOS

Version Information

Cursor 3.9.16 (VS Code 1.105.1) · macOS 26.5.1

Does this stop you from using Cursor?

No - Cursor works, but with this issue

7

Hi @OmryA , Thanks for the forum post! You’ve diagnosed this accurately, and we’ve confirmed what’s happening on our side.

When your context is summarized, we carry over the skills attached to your most recent message, along with the skills catalog itself. Skills the agent discovered and read earlier in the session get folded into the summary text rather than kept as active instructions, so afterward the agent still knows they exist but can sometimes stop applying their steps. That’s the behavior you saw.

On the tool side, the tool descriptions and permission options (including the network permission) are rebuilt every turn, so that reference is always present. What gets lost is the specific “re-run with this permission” hint from the earlier failed command’s output, which is what led to the retry loop.

A few things that help today:

  • Re-attach the skill after a summary. Your skill-reload step is exactly right: pull it back in with / or @ so its procedures apply again.
  • For commands that need network beyond the allowlist, request full_network directly.
  • One note for Allowlist (with Sandbox): escalating permissions doesn’t always bypass the sandbox on its own. Some commands need your approval to run outside it, so if a command stays restricted after you add a permission, that approval step is usually why.

We’ve already improved how attached skills carry across a summary, and we’re now looking at re-applying skills that were read mid-session and preserving that recovery hint across summarization. I’ll keep you updated with any changes to this.

8

Thanks @kevinn — that matches exactly what I saw, and it’s great to hear attached-skill carryover is already improved with re-applying mid-session skills and preserving the recovery hint on the roadmap.

The distinction you drew is a really useful mental model: skills attached to the most recent message (plus the catalog) survive a summary, but skills the agent read mid-session get folded into summary text — so it still knows they exist but stops applying their steps. And on the tool side, the descriptions/permissions are rebuilt each turn, so what’s actually lost is the “re-run with this permission” hint from the earlier failed command’s output.

Noted on the Allowlist (with Sandbox) point too — that escalating a permission doesn’t always bypass the sandbox without the separate approval step. That lines up with what I saw when ["all"] stayed restricted. I’ll keep re-attaching skills after a summary and requesting full_network directly. Appreciate the confirmation and the clear breakdown.