[Fix] Context limit in task header stays stale when user switches provider mid-task and restores

[zoomote]

Opened on behalf of Toray Altas. View the task or mention @zoomote for follow-up asks.

Related GitHub Issue

Closes: #970

Description

The task header's context-usage bar derives its context-window denominator from the live global apiConfiguration, while the token numerator comes from the task's persisted messages. On the stop → switch provider → restore flow, createTaskWithHistoryItem unconditionally reactivated the provider profile stored in HistoryItem.apiConfigName, silently reverting the provider switch the user had just made. The header then kept dividing by the old provider's context window (e.g., 128k) against the accumulated token count, so the limit never updated and the bar could exceed 100%.

The fix is a single guard in createTaskWithHistoryItem: when restoring a task, if the user's currently active provider profile differs from the history item's stale sticky profile, the current profile is kept (no reactivation) and the history item's apiConfigName is corrected so the new selection persists on the next save. When the profiles match, the original restore path runs unchanged. The webview needs no change — the bar follows apiConfiguration automatically once restore stops reverting it.

Test Procedure

• Updated ClineProvider.sticky-profile.spec.ts: new regression test verifies that restoring a task whose saved profile differs from the current profile does not reactivate the stale profile and updates the sticky name to the current one; a companion test verifies the restore path still runs when the profiles match. Existing restore-path tests (mode override, missing profile, failing profile, empty profile) were kept intact by aligning their fixtures with the seeded current profile.
• pnpm test passes (full monorepo suite), pnpm lint and pnpm check-types pass.
• Manual repro from the issue: start a task with a 128k-context provider, stop it, switch to a 256k provider, restore the task — the header context limit now reflects the new provider instead of the old one.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

No UI components were modified; this is an extension-host behavior fix. The header bar updates as a consequence of the provider profile no longer being reverted on restore.

Documentation Updates

• Yes, documentation updates are required — see the paired Zoo-Code-Docs PR linked under "Related PRs", which updates the "Per-Task Profile Persistence" section to describe the new resume behavior.

Related PRs

• Zoo-Code-Docs: [Docs] Update per-task profile persistence resume behavior Zoo-Code-Docs#16

Additional Notes

The same guard also covers checkpoint restore and parent-task resume after subtasks, since both flow through createTaskWithHistoryItem — consistent with the "current profile wins on restore" semantics.

Get in Touch

Reachable via the linked Roomote task or GitHub mentions.

Linked work items

Closes #970

[zoomote]

No code issues found. See task

_{Reviewed 9f81b99}

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/core/webview/ClineProvider.ts	92.30%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!