Add handleRestoreCheckpoint to ChatSessionContentProvider API with UI support for contributed sessions

[Copilot]

Description

Restore Checkpoint currently only works for the default agent, which uses full history-based restoration. External agents (e.g., Claude SDK) that track state via user message IDs cannot customize this behavior. Additionally, the checkpoint UI was hidden for all contributed (non-default) session targets because they are locked to the coding agent.

Changes

API

• Added optional handleRestoreCheckpoint(resource, requestId, token) to ChatSessionContentProvider
• Added supportsCheckpoints?: boolean to ChatSessionCapabilities — extensions declare checkpoint support at registration time
• No version bump required (additive changes)

Implementation

• Extended protocol: ExtHostChatSessionsShape.$handleRestoreCheckpoint
• Wired ExtHost ↔ MainThread handler
• Added IChatSessionsService.getContentProvider() for provider access
• Added IChatSessionsService.supportsCheckpointsForSessionType() to query capabilities
• Passed supportsCheckpoints through registration: ExtHost → Protocol → MainThread → Service
• Modified chatEditingActions.ts to invoke provider handler if present (before the editing session guard), else fall back to default snapshot restoration

UI Changes

• Added chatSessionSupportsCheckpoints context key, set when locking to a coding agent with checkpoint support
• Updated lockToCodingAgent to accept { restorable } option — callers (chatEditor, chatViewPane, chatInputPart) check supportsCheckpointsForSessionType() and pass it through
• Updated menu when clauses for RestoreCheckpoint, RestoreLastCheckpoint, and UndoRequests actions to use ContextKeyExpr.or(lockedToCodingAgent.negate(), sessionSupportsCheckpoints) — checkpoint UI now shows for contributed session targets that declare checkpoint support

Example Usage

// Register with supportsCheckpoints capability
vscode.chat.registerChatSessionContentProvider(
  'my-scheme',
  myProvider,
  myParticipant,
  { supportsCheckpoints: true }
);

class MyContentProvider implements vscode.ChatSessionContentProvider {
  // ... other methods ...
  
  async handleRestoreCheckpoint(
    resource: vscode.Uri, 
    requestId: string, 
    token: vscode.CancellationToken
  ): Promise<void> {
    // Custom restoration logic using user message IDs
    await this.restoreToMessageId(requestId);
  }
}

Providers not implementing the method continue using default behavior. Providers that register with supportsCheckpoints: true will see checkpoint UI even when using a non-default session target.

Original prompt

The ChatContentProvider API should have some way for implementers to handle when a Restore Checkpoint is called.

As far I can tell, Restore Checkpoint only works in the default agent and the way it works really only would work for the default agent which can reason with a full history.

Claude Agent SDK which supports checkpointing, does not have a way to reason with a full history and instead needs to keep track of its own history and checkpoint using user message ids.

Anyway, I think you get the idea, how could I expose a way for the ContentProvider to allow me to handle restore checkpoints

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[TylerLeonhardt]

@copilot you don't need to bump the version if it's purely additive

also, before this change, it seems like the restore checkpoint UI does not show up for non-default agents.

Is there a UI change here that actually enables that UI based on the capabilities of the content provider?

[Copilot]

@copilot you don't need to bump the version if it's purely additive

also, before this change, it seems like the restore checkpoint UI does not show up for non-default agents. ...

Fixed in e99a31c - reverted the version bump since the change is purely additive.

Regarding the UI: The restore checkpoint UI already shows for non-coding-agent sessions via ChatContextKeys.lockedToCodingAgent.negate() in the menu's when clause (line 595). Since handleRestoreCheckpoint is optional, no UI changes are needed - the implementation gracefully falls back to default snapshot restoration when the handler isn't implemented, so the existing UI behavior is appropriate.

[TylerLeonhardt]

@copilot no you are wrong. I don't see the Restore Checkpoint UI when I use any other Session Target other than Local (the default). Why is that?

[Copilot]

@copilot no you are wrong. I don't see the Restore Checkpoint UI when I use any other Session Target other than Local (the default). Why is that?

You're right — contributed session types are locked to the coding agent via lockToCodingAgent(), which sets restorable: false and the lockedToCodingAgent context key, hiding all checkpoint UI.

Fixed in 08ec2a5:

1. Added supportsCheckpoints to ChatSessionCapabilities — extensions declare this at registration time
2. lockToCodingAgent now accepts { restorable } option — callers check supportsCheckpointsForSessionType() and pass it through
3. Added chatSessionSupportsCheckpoints context key
4. Updated menu when clauses to use ContextKeyExpr.or(lockedToCodingAgent.negate(), sessionSupportsCheckpoints) — checkpoint UI shows for any session where either it's not locked OR it declares checkpoint support
5. Content provider's handleRestoreCheckpoint is invoked before the editing session guard, so contributed sessions without an editing session can still restore checkpoints