Enable Copilot CLI users to receive and respond to agent questions through channels beyond the terminal—Slack, SMS, email, mobile apps, or custom integrations. This unlocks unattended/background agent workflows where users aren't watching the terminal.

Problem Statement

Today, when Copilot CLI needs user input (clarifying questions, design decisions, approvals), it blocks and waits for terminal input. This works well for interactive sessions but breaks down in key scenarios:

1. Sandboxed environments: Agent runs in a container/VM without terminal access
2. Long-running tasks: User kicks off a task and walks away; agent gets stuck waiting
3. CI/CD integration: Automated pipelines where human approval is needed mid-flow
4. Mobile/remote users: User is away from their desk but could respond via phone

User pain point: "I started a big refactoring task, went to lunch, came back and Copilot had been waiting 45 minutes for me to pick a database."

Target Users

User Scenarios

Scenario 1: The Coffee Break

Sarah starts a large codebase migration task and goes to get coffee. Copilot encounters an ambiguous situation and needs to ask whether to preserve backward compatibility or do a clean break.

Instead of blocking, Copilot sends the question to Sarah's configured Slack. She sees the notification on her phone, taps "Preserve backward compatibility", and Copilot continues—all while she's still in line for her latte.

Scenario 2: The Sandbox Agent

Marcus runs Copilot agents in Kubernetes pods for automated code maintenance. The pods have no terminal access.

He configures an HTTP endpoint that routes questions to his team's #agent-questions Slack channel. When the agent needs human judgment, the team sees the question, discusses briefly, and one person clicks to respond. The agent receives the answer and continues.

Scenario 3: The Approval Gate

Platform team uses Copilot to propose infrastructure changes. Before applying any Terraform, they want explicit human approval.

They configure an input channel that sends approval requests to PagerDuty. The on-call engineer gets paged, reviews the proposed changes in context, and approves via the PagerDuty app. Full audit trail is maintained.

Scenario 4: The Hybrid Response

Dev is at their terminal but also has Slack open on a second monitor. Copilot asks a question. Dev can respond either by typing in the terminal OR by clicking a button in Slack—whichever is faster. First response wins.

User Experience

Configuration (One-time setup)

User adds a config file to their repo:

.github/copilot/input-channels.json

Minimal example:

{
  "version": 1,
  "inputChannels": [
    {
      "name": "my-slack-bot",
      "endpoint": "https://my-app.example.com/copilot/ask",
      "timeoutSec": 300
    }
  ]
}

That's it. No code changes to Copilot, no feature flags, no special setup.

Runtime Behavior

When Copilot calls ask_user:

1. All channels race: Terminal input, voice (if available), and all configured external channels start simultaneously
2. User sees question in terminal AND receives notification via configured channels
3. First response wins: Whichever channel the user responds through first is accepted
4. Others are cancelled: Remaining channels receive cancellation signal (dismiss notifications, clean up)
5. Agent continues: With the user's answer, regardless of source

User-Visible Changes

Key Capabilities

Must Have (P0)

• Config-driven channel registration - JSON file in repo, no code changes
• HTTP endpoint support - POST to user's service with question payload
• Race semantics - First response wins, others cancelled
• Graceful degradation - External channel failure doesn't break CLI input
• Environment variable interpolation - Secrets via ${VAR_NAME} in config

Should Have (P1)

• Async/polling support - For channels that can't block (most real-world services)
• Configurable timeout per channel - Different SLAs for different channels
• Cancellation protocol - Tell external service to stop notifying user
• Telemetry - Which channel responded, response time, failure rates

Nice to Have (P2)

• Webhook/callback mode - External service calls back instead of CLI polling
• Channel conditions - Only use certain channels for certain question types
• Multiple response aggregation - Wait for consensus across channels
• Built-in Slack/Teams integrations - Zero-config for common platforms

Success Metrics

Non-Goals (Out of Scope)

• Built-in Slack/Teams apps - Users bring their own integration service (we provide the protocol)
• Response validation - We trust the external service to return valid responses
• Channel-specific UX - Rich formatting, buttons, etc. are the external service's responsibility
• Multi-user routing - External service decides who to notify (we just send the question)
• Persistent question queue - If agent dies, pending questions are lost

Technical Constraints

1. No new dependencies - HTTP fetch is sufficient; no Slack SDK, etc.
2. Backward compatible - Existing setups work unchanged; feature is opt-in
3. Security boundary - Config only loaded from trusted repo paths (.github/)
4. Timeout sanity - Max 30 minutes to prevent infinite hangs
5. Stateless protocol - Each question is independent; no session affinity required

Open Questions for Engineering

1. Polling interval - Fixed vs. exponential backoff? Who controls it—CLI or service?
2. Partial responses - Should we support "thinking..." status updates to show user is typing?
3. Channel priority - If two channels respond simultaneously, which wins? Config order? Timestamp?
4. Local development - How do users test their channel integration locally?
5. Error feedback - How much detail do we show when a channel fails?

Appendix: Protocol Overview

External services implement a simple HTTP contract:

Request (CLI → Service):

{
  "requestId": "uuid",
  "question": "Which database?",
  "choices": ["PostgreSQL", "MySQL"],
  "allowFreeform": true
}

Response (Service → CLI):

{
  "status": "completed",
  "answer": "PostgreSQL",
  "wasFreeform": false
}

Or for async:

{
  "status": "pending",
  "pollUrl": "/status/uuid"
}

Full protocol spec available in technical design doc.

Related Documents

• Technical Design Spec - Implementation details, schemas, architecture
• Voice Call Integration (existing) - Reference implementation of racing pattern