copilot --resume no longer allows new session with deterministic id

[mcaden]

Describe the bug

copilot --help specifically states:

# Start a new session with a specific UUID
$ copilot --resume=0cb916db-26aa-40f2-86b5-1ba81b225fd2

Until today, this worked fine. However, it now results in:

Error: No session, task, or name matched '0cb916db-26aa-40f2-86b5-1ba81b225fd2'.

To resume by session or task ID:  copilot --resume=<id>
To resume by name:                copilot --resume=<name>
To name a new session:            copilot --name=<name>
To pick from existing sessions:   copilot --resume

This changes behavior and is counter to what exists in the help.

Affected version

GitHub Copilot CLI 1.0.49-6

Steps to reproduce the behavior

1. generate a new guid that you don't have a session for.
2. Attempt to launch with copilot --resume <session guid>

Expected behavior

It is expected that copilot will start a new session and use the provided GUID. Instead, it fails and provides an error.

Additional context

No response

[LangSensei]

+1

[milope]

+Many :). This appears to have impacted many folks in our team as well

[khuongntrd]

It looks like it's changed with version 1.0.51 - 2026-05-20:

--session-id=<id> resumes known sessions or tasks, and starts new sessions with a specific UUID

[tiagonbotelho]

Hi folks, thank you for raising this issue and apologies for breaking everyone's workflows, we've recently moved away from having --resume creating a session using a provided UUID since it didn't semantically align with the intent of that flag (which is to resume an existing session).

However, we've since added a --session-id flag which does exactly what --resume was doing before, hope it helps 🙏

I'm closing this issue as a result