sessions.fork fails when SessionFs is enabled

[chenmohan123]

sessions.fork fails when SessionFs is enabled

Summary

In our Electron demo using @github/copilot-sdk 0.2.2, native sessions.fork({ sessionId, toEventId }) works in a real environment when SessionFs is disabled, but fails repeatedly when SessionFs is enabled.

This looks like a compatibility bug between sessions.fork and SessionFs, rather than a general fork failure.

Environment

• SDK: @github/copilot-sdk 0.2.2
• Host app: Electron
• OS: Windows
• Node: Node 22
• Session model:
  • Electron main process owns CopilotClient and sessions
  • Renderer calls main process through preload IPC
• SessionFs:
  • Local SessionFs provider enabled through SDK-supported config / handler path

What we verified first

Before treating this as an SDK bug, we reduced our app logic to SDK-native semantics.

The app calls the native SDK API directly:

client.rpc.sessions.fork({
  sessionId,
  toEventId
});

We do not do any of the following:

• fork full session then truncate manually
• rewrite history locally
• replay turns
• invent a private protocol on top of fork

So the failure below is happening on the native SDK fork path.

Expected behavior

Case A: SessionFs disabled

When SessionFs is disabled, sessions.fork({ sessionId, toEventId }) should create a new session and respect the checkpoint boundary.

This path works for us.

Case B: SessionFs enabled

When SessionFs is enabled, sessions.fork({ sessionId, toEventId }) should also work, or at least fail with a documented unsupported-capability error if that combination is not supported.

Instead, we repeatedly get storage/state-related failures.

Actual behavior

With SessionFs enabled, triggering checkpoint fork surfaces errors like:

Error invoking remote method 'copilot:fork-session': Error: Request sessions.fork failed with message: Session bc7adb9f-63b8-48bc-8ced-65f3489e667c not found or has no persisted events

We have also observed other variants in the same SessionFs-enabled scenario:

Request sessions.fork failed with message: No session found for sessionId: ...

Request sessionsFs.mkdir failed with message: No session found for sessionId: ...

Failed to append to JSONL file state\events.jsonl

Repro steps

Repro A: baseline fork works

1. Start the Electron app.
2. Ensure SessionFs is disabled.
3. Authenticate and use a Copilot-backed model.
4. Send at least two user turns.
5. Call sessions.fork({ sessionId, toEventId }) from a checkpoint.
6. Observe that a new session is created and fork works on at least one real path.

Repro B: SessionFs-enabled failure

1. Start the Electron app.
2. Enable SessionFs.
3. Authenticate and use a Copilot-backed model.
4. Send at least two user turns.
5. Call sessions.fork({ sessionId, toEventId }) from a checkpoint.
6. Observe one of the errors above, especially:
   • not found or has no persisted events
   • No session found for sessionId
   • sessionsFs.mkdir failed

Why this looks like an SDK bug

• The same fork flow works when SessionFs is disabled.
• The app uses the SDK-native fork API directly.
• The failure mode is tied to session persistence / SessionFs state, not to UI logic.
• The failing messages suggest that fork cannot reliably see the source session state once SessionFs is involved.

Question

Is sessions.fork expected to be supported when SessionFs is enabled?

If yes, this appears to be a bug in the SessionFs + fork interaction.

If no, could the SDK return a clearer capability or unsupported-operation signal instead of state/persistence errors like:

• not found or has no persisted events
• sessionsFs.mkdir failed
• No session found for sessionId

Additional note

We intentionally separate these two conclusions:

• sessions.fork itself is not completely broken for us
• the combination of sessions.fork + SessionFs appears unstable / broken