SDK server reports ready without auth, then Slack session creation fails generically

[meagancojocar]

Describe the bug

A user invoking GitHub Copilot from a Slack DM received:

I couldn't create a session for this chat. Please try again.

The initial Copilot CLI SDK server started and reported itself ready, but it had no COPILOT_SDK_AUTH_TOKEN in its environment. It never initialized a workspace or created a session, leaving the Slack user with only a generic failure message.

This affected one Slack DM user during a headless SDK-backed Copilot interaction. No repository was involved; the working directory was /root on Linux.

Affected version

1.0.78

Steps to reproduce the behavior

1. Start Copilot CLI in SDK server mode without authentication:

   copilot --server --stdio --no-auto-update --no-auto-login
   

2. Observe that the process logs:

   Starting CLI in server mode (stdio)
   CLI server ready (stdio mode, Rust JSON-RPC engine)
   Server started, waiting for requests
   

3. Attempt to create a chat session from the Slack integration.

4. Observe the generic user-facing error: I couldn't create a session for this chat. Please try again.

5. Retry with the SDK auth token configured:

   copilot --server --stdio --no-auto-update --auth-token-env COPILOT_SDK_AUTH_TOKEN --no-auto-login
   

6. The workspace and session are then created successfully:

   Workspace initialized: <session-id> (checkpoints: 0)
   Created session: <session-id>
   

Expected behavior

The integration should always pass authentication when launching the SDK server. If authentication is missing, the server should fail fast before reporting ready, return a structured authentication error to its caller, and surface an actionable message to the user rather than a generic session-creation failure.

Additional context

• Context: GitHub Copilot invoked from a Slack DM through a headless SDK server.
• OS: Linux.
• The unauthenticated process remained running after the failed attempt.
• The successful retry had COPILOT_SDK_AUTH_TOKEN present and used --auth-token-env COPILOT_SDK_AUTH_TOKEN.
• Local session-store integrity, filesystem permissions, disk space, and inode availability were healthy.
• No matching issue was found for this exact missing-auth launch path.

Recommended fix

1. Validate the configured auth source before the server announces readiness or accepts session.create.
2. Make the SDK launcher require and consistently pass --auth-token-env COPILOT_SDK_AUTH_TOKEN.
3. Return a typed authentication_missing error through JSON-RPC so integrations can distinguish this from storage, network, and model-policy failures.
4. Surface a user-facing remediation such as: Copilot authentication was not configured for this chat. Please reconnect GitHub Copilot and retry.
5. Terminate or recycle an unauthenticated server process rather than leaving it alive for subsequent requests.

[rishidevcli54-mcp]

Describe the bug

A user invoking GitHub Copilot from a Slack DM received:

I couldn't create a session for this chat. Please try again.

The initial Copilot CLI SDK server started and reported itself ready, but it had no COPILOT_SDK_AUTH_TOKEN in its environment. It never initialized a workspace or created a session, leaving the Slack user with only a generic failure message.

This affected one Slack DM user during a headless SDK-backed Copilot interaction. No repository was involved; the working directory was /root on Linux.

Affected version

1.0.78

Steps to reproduce the behavior

1. Start Copilot CLI in SDK server mode without authentication:

   copilot --server --stdio --no-auto-update --no-auto-login
   

2. Observe that the process logs:

   Starting CLI in server mode (stdio)
   CLI server ready (stdio mode, Rust JSON-RPC engine)
   Server started, waiting for requests
   

3. Attempt to create a chat session from the Slack integration.
4. Observe the generic user-facing error: I couldn't create a session for this chat. Please try again.
5. Retry with the SDK auth token configured:

   copilot --server --stdio --no-auto-update --auth-token-env COPILOT_SDK_AUTH_TOKEN --no-auto-login
   

6. The workspace and session are then created successfully:

   Workspace initialized: <session-id> (checkpoints: 0)
   Created session: <session-id>
   

Expected behavior

The integration should always pass authentication when launching the SDK server. If authentication is missing, the server should fail fast before reporting ready, return a structured authentication error to its caller, and surface an actionable message to the user rather than a generic session-creation failure.

Additional context

• Context: GitHub Copilot invoked from a Slack DM through a headless SDK server.
• OS: Linux.
• The unauthenticated process remained running after the failed attempt.
• The successful retry had COPILOT_SDK_AUTH_TOKEN present and used --auth-token-env COPILOT_SDK_AUTH_TOKEN.
• Local session-store integrity, filesystem permissions, disk space, and inode availability were healthy.
• No matching issue was found for this exact missing-auth launch path.

Recommended fix

1. Validate the configured auth source before the server announces readiness or accepts session.create.
2. Make the SDK launcher require and consistently pass --auth-token-env COPILOT_SDK_AUTH_TOKEN.
3. Return a typed authentication_missing error through JSON-RPC so integrations can distinguish this from storage, network, and model-policy failures.
4. Surface a user-facing remediation such as: Copilot authentication was not configured for this chat. Please reconnect GitHub Copilot and retry.
5. Terminate or recycle an unauthenticated server process rather than leaving it alive for subsequent requests.

[rishidevcli54-mcp]

Workspace initialized: (checkpoints: 0)
Created session: ### **/

• /**

[rishidevcli54-mcp]

Workspace initialized: (checkpoints: 0)
Created session: ### **/

• /**

Workspace initialized: (checkpoints: 0) Created session: ### **/

• /**

__Duplicate of #4474 - 1. __Duplicate of #4474 - __Duplicate of #4473 @__Duplicate #@__Duplicate__Duplicate__Duplicate of #4473

[rishidevcli54-mcp]

Workspace initialized: (checkpoints: 0)
Created session: ### **/

• /**

Workspace initialized: (checkpoints: 0) Created session: ### **/

• /**

__Duplicate of #4474 - 1. __Duplicate of #4474 - __Duplicate of #4473 @__Duplicate #@__Duplicate__Duplicate__Duplicate of #4473

[miguelrenatoaguirre-cmd]

Hey. I would like to be part of your working space what are the requirements.