Describe the feature or problem you'd like to solve
copilot --name <name> creates a new named session, but it does not resume an existing session with that name. After the first launch, users and automation must know whether the session exists before selecting --name <name> or --resume <name>.
The same distinction breaks CLI relaunches. A session started with copilot --name project-a can fail during /update when the replacement process receives both the original --name and an internal --session-id:
error: option '-n, --name <name>' cannot be used with option '--session-id <id>' when it resolves to an existing or remote session or task.
--name only names a brand-new session created by --session-id=<new-uuid>; the resolved session was not renamed.
Proposed solution
Give copilot --name <name> create-or-resume behavior. --name should use the same name lookup and matching rules as --resume <name>:
- If no session matches, create a session with that name.
- If exactly one session matches, resume that session.
- If multiple sessions match, follow the current
--resume <name> ambiguity behavior. Do not create another session.
- Resume the selected session when
/restart, /update, or another command relaunches the CLI. A retained --name should not fail because the session now exists or because the relaunch also carries an internal session ID.
--resume should remain available for three uses: session IDs, the session picker, and existing workflows. Users and automation could then use one repeatable command whenever a stable name identifies the session.
Example prompts or workflows
- The first
copilot --name project-a invocation creates a named session.
- A later
copilot --name project-a invocation resumes that session.
/update or /restart resumes that session without a flag conflict.
- An alias or script can keep invoking
copilot --name project-a without first querying session state.
Additional context
Issue #3332 reports /restart failing in a session created with --name. The requested semantics address that failure and the broader need for one repeatable name-based command.
Describe the feature or problem you'd like to solve
copilot --name <name>creates a new named session, but it does not resume an existing session with that name. After the first launch, users and automation must know whether the session exists before selecting--name <name>or--resume <name>.The same distinction breaks CLI relaunches. A session started with
copilot --name project-acan fail during/updatewhen the replacement process receives both the original--nameand an internal--session-id:Proposed solution
Give
copilot --name <name>create-or-resume behavior.--nameshould use the same name lookup and matching rules as--resume <name>:--resume <name>ambiguity behavior. Do not create another session./restart,/update, or another command relaunches the CLI. A retained--nameshould not fail because the session now exists or because the relaunch also carries an internal session ID.--resumeshould remain available for three uses: session IDs, the session picker, and existing workflows. Users and automation could then use one repeatable command whenever a stable name identifies the session.Example prompts or workflows
copilot --name project-ainvocation creates a named session.copilot --name project-ainvocation resumes that session./updateor/restartresumes that session without a flag conflict.copilot --name project-awithout first querying session state.Additional context
Issue #3332 reports
/restartfailing in a session created with--name. The requested semantics address that failure and the broader need for one repeatable name-based command.