Omnichannel Input for Copilot CLI/SDK

[patniko]

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 Type	Scenario
Solo developer	Kicks off tasks, wants to respond from phone while AFK
Platform engineer	Runs Copilot in sandboxed CI environment, needs Slack integration for approvals
Team lead	Wants agent questions routed to team channel for collaborative decisions
Enterprise admin	Needs audit trail of human-in-the-loop decisions across channels

---

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

Before	After
Question appears only in terminal	Question appears in terminal + configured channels
Must be watching terminal to respond	Can respond from anywhere
Agent blocks indefinitely	Agent has configurable timeout per channel
No visibility into what agent asked	Questions logged/auditable via external systems

---

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

Metric	Target
Config-to-working time	< 15 minutes for technical user
Response latency overhead	< 500ms added vs terminal-only
Channel failure rate	< 1% of requests fail due to channel issues
Adoption	10% of active CLI users configure at least one channel within 6 months

---

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

[friggeri]

I'm not sure this is the right approach, we already have a story for leveraging the CLI in server mode as part of the SDK, but currently it's a XOR: you can't both run the TUI and the SDK server.

A lot of what you're describing would be possible by enabling both at the same time: run the CLI, it spins up an SDK server in the background in parallel with running the TUI. Inputs can either come in manually through the TUI or programmatically through the SDK.

All the examples you're listing are things that could be accomplished with this, for example in the first scenario: The user could have a small app built around the SDK that runs in the background, it subscribes to the event stream. when it gets a session.ask event it sends a message through slack, when it gets the response back from the user, it calls session.respondToAsk or whatever method we have there.

All of this fits well within the event model we already have, no need to build a different protocol, just need to expose the existing one on top of the CLI.

The main change from a CLI perspective is that there are a bunch of places where we manage the UI state locally/independently from the event stream (eg. there is no event to say to close an "ask" that we can emit)