The Copilot SDK lets you add the same AI that powers Copilot Chat to your own applications. I wanted to see what that looks like in practice, so I built an issue triage app called IssueCrush. Here’s what I learned and how you can get started. If you’ve ever maintained an open source project, or worked on a team with active repositories, you know the feeling. You open GitHub and see that notification badge: 47 issues. Some are bugs, some are feature requests, some are questions that should be discussions, and some are duplicates of issues from three years ago. The mental overhead of triaging issues is real. Each one requires context-switching: read the title, scan the description, check the labels, think about priority, decide what to do. Multiply that by dozens of issues across multiple repositories, and suddenly your brain is mush. I wanted to make this faster. And with the GitHub Copilot SDK, I found a way. Enter IssueCrush: Swipe right to ship IssueCrush shows your GitHub issues as swipeable cards. Left to close, right to keep. When you tap “Get AI Summary,” Copilot reads the issue and tells you what it’s about and what to do with it. Instead of reading through every lengthy description, maintainers can get instant, actionable context to make faster triage decisions. Here’s how I integrated the GitHub Copilot SDK to make it happen. The architecture challenge The first technical decision was figuring out where to run the Copilot SDK. React Native apps can’t directly use Node.js packages, and the Copilot SDK requires a Node.js runtime. Internally, the SDK manages a local Copilot CLI process and communicates with it over JSON-RPC. Because of this dependency on the CLI binary and a Node environment, the integration must run server-side rather than directly in a React Native app. This means the server must have the Copilot CLI installed and available on the system PATH. I settled on a server-side integration pattern: Here’s why this setup works: Single SDK instance shared across all clients, so you’re not spinning up a new connection per mobile client. The server manages one instance for every request. Less overhead, fewer auth handshakes, simpler cleanup. Server-side secrets for Copilot authentication, to keep credentials secure. Your API tokens never touch the client. They live on the server where they belongnot inside a React Native bundle someone can decompile. Graceful degradation when AI is unavailable, so you can still triage issues even if the Copilot service goes down or times out. The app falls back to a basic summary. AI makes triage faster, but it shouldn’t be a single point of failure. Logging of requests for debugging and monitoring, because every prompt and response passes through your server. You can track latency, catch failures, and debug prompt issues without bolting instrumentation onto the mobile client. Before you build something like this, you need: The Copilot CLI installed on your server. A GitHub Copilot subscription, or a BYOK configuration with your own API keys. The Copilot CLI authenticated. Run copilot auth on your server, or set a COPILOT_GITHUB_TOKEN environment variable. How to implement the Copilot SDK integration The Copilot SDK uses a session-based model. You start a client (which spawns the CLI process), create a session, send messages, then clean up. const CopilotClient, approveAll = await import('@github/copilot-sdk'); let client = null; let session = null; try // 1. Initialize the client (spawns Copilot CLI in server mode) client = new CopilotClient(); await client.start(); // 2. Create a session with your preferred model session = await client.createSession( model: 'gpt-4.1', onPermissionRequest: approveAll, ); // 3. Send your prompt and wait for response const response = await session.sendAndWait( prompt ); // 4. Extract the content if (response && response.data && response.data.content) const summary = response.data.content; // Use the summary... finally // 5. Always clean up if (session) await session.disconnect().catch(() => ); if (client) await client.stop().catch(() => ); Key SDK patterns 1. Lifecycle management The SDK follows a strict lifecycle: start() → createSession() → sendAndWait() → disconnect() → stop(). Here’s something I learned the hard way: failing to clean up sessions leaks resources. I spent two hours debugging memory issues before realizing I’d forgotten a disconnect() call. Wrap every session interaction in try/finally. The .catch(() => ) on cleanup calls prevents cleanup errors from masking the original error. 2. Prompt engineering for triage Prompt structure gives the model enough context to do its job. I provide structured information