Skip to content
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

Thanks for your interest in contributing!

This repository contains the Copilot SDK, a set of multi-language SDKs (Node/TypeScript, Python, Go, .NET, Rust) for building applications with the GitHub Copilot agent, maintained by the GitHub Copilot team.
This repository contains the Copilot SDK, a set of multi-language SDKs (Node/TypeScript, Python, Go, .NET, Java, and Rust) for building applications with the GitHub Copilot agent, maintained by the GitHub Copilot team.

Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE).

Expand Down
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@

Agents for every app.

Embed Copilot's agentic workflows in your application—now available in public preview as a programmable SDK for Python, TypeScript, Go, .NET, and Java. A Rust SDK is also available in technical preview.
Embed Copilot's agentic workflows in your application with the GitHub Copilot SDK for Python, TypeScript, Go, .NET, Java, and Rust.

The GitHub Copilot SDK exposes the same engine behind Copilot CLI: a production-tested agent runtime you can invoke programmatically. No need to build your own orchestration—you define agent behavior, Copilot handles planning, tool invocation, file edits, and more.

Expand All @@ -37,7 +37,7 @@ Quick steps:
1. **(Optional) Install the Copilot CLI**

For Node.js, Python, and .NET SDKs, the Copilot CLI is bundled automatically and no separate installation is required.
For the Go, Java and Rust SDKs, [install the CLI manually](https://github.com/features/copilot/cli) or ensure `copilot` is available in your PATH unless you opt into their application-level CLI bundling features.
For Go, Java, and Rust, [install the CLI manually](https://github.com/features/copilot/cli) or ensure `copilot` is available in your PATH. Go and Rust also expose application-level CLI bundling features.

2. **Install your preferred SDK** using the commands above.

Expand Down Expand Up @@ -88,7 +88,7 @@ See the **[Authentication documentation](./docs/auth/index.md)** for details on

No — for Node.js, Python, and .NET SDKs, the Copilot CLI is bundled automatically as a dependency. You do not need to install it separately.

For Go, Java and Rust SDKs, the CLI is **not** bundled by default. Install the CLI manually, ensure `copilot` is available in your PATH, or opt into their application-level CLI bundling features.
For Go, Java, and Rust SDKs, the CLI is **not** bundled by default. Install the CLI manually or ensure `copilot` is available in your PATH. Go and Rust also expose application-level CLI bundling features.

Advanced: You can override the CLI binary or connect to an external server. See the individual SDK README for language-specific options.

Expand Down Expand Up @@ -117,7 +117,7 @@ All models available via Copilot CLI are supported in the SDK. The SDK also expo

### Is the SDK production-ready?

The GitHub Copilot SDK is currently in Public Preview. While it is functional and can be used for development and testing, it may not yet be suitable for production use.
The GitHub Copilot SDK is generally available and follows semantic versioning. See [CHANGELOG.md](./CHANGELOG.md) for release notes.

### How do I report issues or request features?

Expand Down
4 changes: 3 additions & 1 deletion docs/auth/authenticate.md
Original file line number Diff line number Diff line change
Expand Up @@ -300,13 +300,15 @@ BYOK allows you to use your own API keys from model providers like Azure AI Foun

When multiple authentication methods are available, the SDK uses them in this priority order:

1. **Explicit `gitHubToken`** - Token passed directly to SDK constructor
1. **Explicit `gitHubToken`** - Token passed directly to the SDK client or session configuration
1. **HMAC key** - `CAPI_HMAC_KEY` or `COPILOT_HMAC_KEY` environment variables
1. **Direct API token** - `GITHUB_COPILOT_API_TOKEN` with `COPILOT_API_URL`
1. **Environment variable tokens** - `COPILOT_GITHUB_TOKEN` → `GH_TOKEN` → `GITHUB_TOKEN`
1. **Stored OAuth credentials** - From previous `copilot` CLI login
1. **GitHub CLI** - `gh auth` credentials

For multi-user server mode, pass a per-session `gitHubToken` so each session runs with the correct GitHub identity; see [Multi-user and server deployments](../setup/multi-tenancy.md).

## Disabling auto-login

To prevent the SDK from automatically using stored credentials or `gh` CLI auth, use the `useLoggedInUser: false` option:
Expand Down
8 changes: 5 additions & 3 deletions docs/auth/byok.md
Original file line number Diff line number Diff line change
Expand Up @@ -205,15 +205,17 @@ client.stop().get();
| `baseUrl` / `base_url` | string | **Required.** API endpoint URL |
| `apiKey` / `api_key` | string | API key (optional for local providers like Ollama) |
| `bearerToken` / `bearer_token` | string | Bearer token auth (takes precedence over apiKey) |
| `wireApi` / `wire_api` | `"completions"` \| `"responses"` | API format (default: `"completions"`) |
| `wireApi` / `wire_api` | `"completions"` \| `"responses"` | Select `"completions"` for broad model compatibility (the Chat Completions API); select `"responses"` for multi-turn state management, tool namespacing, and reasoning support (the Responses API). Anthropic models always use the Messages API regardless of this setting. |
| `azure.apiVersion` / `azure.api_version` | string | Azure API version (default: `"2024-10-21"`) |

### Wire API format

The `wireApi` setting determines which OpenAI API format to use:

* **`"completions"`** (default) - Chat Completions API (`/chat/completions`). Use for most models.
* **`"responses"`** - Responses API. Use for GPT-5 series models that support the newer responses format.
* **`"completions"`** (default) - Chat Completions API (`/chat/completions`) for broad model compatibility.
* **`"responses"`** - Responses API for multi-turn state management, tool namespacing, and reasoning support.

Anthropic models always use the Anthropic Messages API regardless of this setting.

### Type-specific notes

Expand Down
6 changes: 6 additions & 0 deletions docs/auth/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,3 +4,9 @@ Choose the authentication method that best fits your deployment scenario for the

* [Authenticate Copilot SDK](authenticate.md): methods, priority order, and examples
* [Bring your own key (BYOK)](./byok.md): use your own API keys from OpenAI, Azure, Anthropic, and more

## Authentication priority

When multiple credentials are configured, an explicit SDK token takes priority, followed by HMAC or direct Copilot API environment authentication, environment variable GitHub tokens, stored Copilot CLI credentials, and then GitHub CLI credentials. See [Authenticate Copilot SDK](authenticate.md#authentication-priority) for details.

For multi-user server mode, pass a per-session `gitHubToken` so each session runs with the correct GitHub identity; see [Multi-user and server deployments](../setup/multi-tenancy.md).
242 changes: 242 additions & 0 deletions docs/features/cloud-sessions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,242 @@
# Cloud sessions

Cloud sessions run Copilot work on GitHub-hosted compute through Mission Control. Use them when your app should create a session that executes remotely instead of starting a local Copilot CLI session on the user's machine or your server.

## Prerequisites

Before creating a cloud session, make sure:

* The user has Copilot access with cloud-agent entitlement.
* The session can authenticate to GitHub, either with a user token or a logged-in Copilot CLI identity.
* You can associate the session with a GitHub repository. This is optional in the SDK type, but recommended so Mission Control and the cloud agent have repository context.
* Organization policies allow remote control and viewing sessions from cloud surfaces.

## Creating a cloud session

Set the create-session `cloud` option to create a cloud session. You can include repository metadata to associate the cloud session with a GitHub repository.

<!-- tabs:start -->

### TypeScript

<!-- docs-validate: skip -->
```typescript
import { CopilotClient } from "@github/copilot-sdk";

const client = new CopilotClient();
await client.start();

const session = await client.createSession({
onPermissionRequest: async () => ({ kind: "approve-once" }),
cloud: {
repository: {
owner: "github",
name: "copilot-sdk",
branch: "main",
},
},
});
```

### Python

<!-- docs-validate: skip -->
```python
from copilot import CopilotClient, CloudSessionOptions, CloudSessionRepository
from copilot.session import PermissionHandler

client = CopilotClient()
await client.start()

session = await client.create_session(
on_permission_request=PermissionHandler.approve_all,
cloud=CloudSessionOptions(
repository=CloudSessionRepository(
owner="github",
name="copilot-sdk",
branch="main",
)
),
)
```

### Go

<!-- docs-validate: skip -->
```go
client := copilot.NewClient(nil)
if err := client.Start(ctx); err != nil {
return err
}

session, err := client.CreateSession(ctx, &copilot.SessionConfig{
Cloud: &copilot.CloudSessionOptions{
Repository: &copilot.CloudSessionRepository{
Owner: "github",
Name: "copilot-sdk",
Branch: "main",
},
},
OnPermissionRequest: func(req copilot.PermissionRequest, inv copilot.PermissionInvocation) (rpc.PermissionDecision, error) {
return &rpc.PermissionDecisionApproveOnce{}, nil
},
})
_ = session
```

### .NET

<!-- docs-validate: skip -->
```csharp
await using var client = new CopilotClient();

var session = await client.CreateSessionAsync(new SessionConfig
{
Cloud = new CloudSessionOptions
{
Repository = new CloudSessionRepository
{
Owner = "github",
Name = "copilot-sdk",
Branch = "main",
},
},
OnPermissionRequest = (req, inv) =>
Task.FromResult(PermissionDecision.ApproveOnce()),
});
```

### Java

<!-- docs-validate: skip -->
```java
import com.github.copilot.CopilotClient;
import com.github.copilot.rpc.*;

try (var client = new CopilotClient()) {
client.start().get();

var session = client.createSession(
new SessionConfig()
.setCloud(new CloudSessionOptions()
.setRepository(new CloudSessionRepository()
.setOwner("github")
.setName("copilot-sdk")
.setBranch("main")))
.setOnPermissionRequest(PermissionHandler.APPROVE_ALL)
).get();
}
```

### Rust

<!-- docs-validate: skip -->
```rust
use github_copilot_sdk::{CloudSessionOptions, CloudSessionRepository, SessionConfig};
use github_copilot_sdk::handler::PermissionResult;

let session = client.create_session(
SessionConfig::default()
.with_cloud(CloudSessionOptions::with_repository(
CloudSessionRepository::new("github", "copilot-sdk").with_branch("main"),
))
.with_permission_handler(|_req, _inv| async {
Ok(PermissionResult::approve_once())
}),
).await?;
```

<!-- tabs:end -->

## Repository association

Comment thread
patniko marked this conversation as resolved.
The `cloud.repository` object associates the cloud session with a GitHub repository:

| Field | Required | Description |
|-------|----------|-------------|
| `owner` | Yes | Repository owner or organization. |
| `name` | Yes | Repository name. |
| `branch` | No | Branch to use for repository context. Omit it to let the runtime choose the default branch or current repository context. |

Repository association is optional in the SDK type, but include it whenever your app knows the target repository. It helps Mission Control display the session in the right context and gives the cloud agent a clearer starting point.

Use `branch` when the work should start from a specific branch. If your app is creating sessions from pull requests, issue triage flows, or deployment workflows, pass the branch that matches the user-visible task.

## Resuming a cloud session

The `cloud` option only applies when creating a new session. To resume an existing cloud session, use the standard resume API for the SDK language:

<!-- docs-validate: skip -->
```typescript
const session = await client.resumeSession("session-id");
```

Do not pass `cloud` again on resume. The saved session metadata determines that the session is cloud-backed, and resume follows the normal session resume path.

## Org policies and entitlements

Cloud session creation can fail when the user or organization is not entitled to cloud-agent execution or when organization-level policies block the flow. In particular, policies for remote control or viewing sessions from cloud surfaces can prevent Mission Control from creating the cloud task.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW @patniko on the cloud side we were able to decouple the --cloud policy from --remote. This means that a user can only enable cloud sandbox for this to work. At the end of the day, --remote is just the underlying tech to make --cloud work.

Cloud sandbox policy is at org/enterprise level at Settings > Sandboxes > Let organizations decide

cc @JasonEtco


When this happens, the runtime reports a `"policy_blocked"` failure reason for cloud task creation. Treat this as an authorization or policy outcome, not as a transient infrastructure failure.

In TypeScript, check for the reason before retrying:

<!-- docs-validate: skip -->
```typescript
try {
await client.createSession({ cloud: { repository } });
} catch (error) {
if ((error as { reason?: string }).reason === "policy_blocked") {
// Show an admin-facing message or link to org policy settings.
}
throw error;
}
```

In languages where SDK errors are represented differently, inspect the surfaced error reason or code and handle `"policy_blocked"` explicitly. Retrying without a policy change is not expected to succeed.

## Integration ID and routing

Cloud sessions are stamped with a `Copilot-Integration-Id` header derived from the `GITHUB_COPILOT_INTEGRATION_ID` environment variable. This integration ID is used by Mission Control for routing, attribution, and integration-specific behavior.

For multi-user server guidance and full integration ID details, see [Multi-tenancy](../setup/multi-tenancy.md).

Mission Control routes SDK-created cloud sessions to the `copilot-developer-sandbox` agent slug. The name is an internal routing slug for the cloud agent and does not mean the session uses the local Windows sandbox.

## Advanced: `COPILOT_MC_BASE_URL`

By default, the runtime derives the Mission Control base URL from the configured Copilot API URL. Set `COPILOT_MC_BASE_URL` only when you need to override that Mission Control endpoint.

This may be required for GitHub Enterprise Server deployments. Confirm the correct value and support status with your GitHub representative before relying on it in production.

<!-- docs-validate: skip -->
```shell
COPILOT_MC_BASE_URL="https://example.com/agents"
```

## Cloud sessions vs. remote sessions

| Capability | Remote sessions | Cloud sessions |
|------------|-----------------|----------------|
| Execution location | Local machine or your server | GitHub-hosted compute |
| Mission Control role | Shares a local session to GitHub web/mobile | Creates and routes the hosted session |
| SDK option | `remote: true` on the client or session | `cloud: { ... }` on create session |
| Resume path | Standard resume | Standard resume |
| Windows sandbox relation | Unrelated | Unrelated |

Use remote sessions when the session should execute where the SDK runtime is already running, but also be accessible from Mission Control. Use cloud sessions when the session should execute on GitHub-hosted compute.

## Troubleshooting

| Symptom | Likely cause | What to check |
|---------|--------------|---------------|
| Cloud session creation returns `"policy_blocked"` | Organization policy blocks remote control or view from cloud flows | Check org Copilot policies and user entitlement |
| Session creates without repository context | `cloud.repository` was omitted | Pass `owner`, `name`, and optionally `branch` |
| Resume ignores a new `cloud` option | `cloud` only applies to new sessions | Resume the existing session normally |
| Confusion with sandbox settings | Windows sandbox and cloud sessions are separate | Do not use `SANDBOX=true` for cloud execution |

## See also

* [Remote Sessions](./remote-sessions.md): share locally hosted sessions through Mission Control
* [Multi-tenancy](../setup/multi-tenancy.md): integration IDs and server deployment patterns
* [Authentication](../auth/index.md): configure GitHub authentication for SDK sessions
2 changes: 1 addition & 1 deletion docs/features/custom-agents.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Custom agents and sub-agent orchestration

Define specialized agents with scoped tools and prompts, then let Copilot orchestrate them as sub-agents within a single session.
Define specialized agents with scoped tools and prompts, then let Copilot orchestrate them as sub-agents within a single session. For dispatching multiple sub-agents in parallel, see [Fleet Mode](./fleet-mode.md).

## Overview

Expand Down
Loading
Loading