Author name: ITMAITY

In June, we experienced three incidents that resulted in degraded performance across GitHub services. June 5 17:47 UTC (lasting 1 hour and 33 minutes) On June 5, 2025, between 17:47 UTC and 19:20 UTC, the Actions service was degraded, leading to run start delays and intermittent job failures. During this period, 47.2% of runs had delayed starts of 14 minutes on average, and 21.0% of runs failed. The impact extended beyond Actions itself; 60% of Copilot Coding Agent sessions were cancelled, and all Pages sites using branch-based builds failed to deploy (though Pages serving remained unaffected). The issue was caused by a spike in load between internal Actions services exposing a misconfiguration that caused throttling of requests in the critical path of run starts. We mitigated the incident by correcting the service configuration to prevent throttling and have updated our deployment process to ensure the correct configuration is preserved moving forward. June 12 17:55 UTC (lasting 3 hours and 12 minutes) On June 12, 2025, between 17:55 UTC and 21:07 UTC, the GitHub Copilot service was degraded and experienced unavailability for Gemini models and reduced availability for Claude models. Users experienced significantly elevated error rates for chat completions, slow response times, timeouts, and chat functionality interruptions across VS Code, JetBrains IDEs, and GitHub Copilot Chat. This was due to an outage affecting one of our model providers. We mitigated the incident by temporarily disabling the affected provider endpoints to reduce user impact. We are working to update our incident response playbooks for infrastructure provider outages and improve our monitoring and alerting systems to reduce our time to detection and mitigation of issues like this one in the future. June 17 19:32 UTC (lasting 31 minutes) On June 17, 2025, between 19:32 UTC and 20:03 UTC, an internal routing policy deployment to a subset of network devices caused reachability issues for certain network address blocks within our datacenters. Authenticated users of the github.com UI experienced 3-4% error rates for the duration of the incident. Authenticated callers of the API experienced 40% error rates. Unauthenticated requests to the UI and API experienced nearly 100% error rates. Actions experienced 2.5% of runs being delayed for an average of 8 minutes and 3% of runs failing. Large File Storage (LFS) requests experienced 1% errors. At 19:54 UTC, the deployment was rolled back, and network availability for the affected systems was restored. At 20:03 UTC, we fully restored normal operations. To prevent similar issues, we are expanding our validation process for routing policy changes. Please follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the GitHub Engineering Blog. The post GitHub Availability Report: June 2025 appeared first on The GitHub Blog. ​ Company news, News & insights, GitHub Availability Report The GitHub Blog

Open source software is open digital infrastructure that our economies and societies rely on. Nevertheless, open source maintenance continues to be underfunded, especially when compared to physical infrastructure like roads or bridges. So we ask: how can the public sector better support open source maintenance?  As part of our efforts to support developers, GitHub’s developer policy team has commissioned a study from Open Forum Europe, Fraunhofer ISI and the European University Institute that explores how one of the open source world’s most successful government programs, the German Sovereign Tech Agency, can be scaled up to the European Union level. That study was published today. Here’s what it says and what you can do to help make the EU Sovereign Tech Fund (EU-STF) a reality. The maintenance challenge There is a profound mismatch between the importance of open source maintenance and the public attention it receives. The demand-side value of open source software to the global economy is estimated at $8.8 trillion, and the European Commission’s own research shows that OSS contributes a minimum of €65-95 billion to the EU economy annually. Basic open source technologies, such as libraries, programming languages, or software development tools, are used in all sectors of the economy, society, and public administrations. Open source is everywhere Open source is valuable Open source is underfinanced 96% of all code bases contain OSS $8.8T demand-side value to global economy 1/3 of OSS maintainers are unpaid 77% of a given code base is OSS €65-95M minimum contribution to annual EU GDP 1/3 are the only maintainer of their OSS project The flip side of everybody benefiting from this open digital infrastructure is that too few feel responsible for paying the tab. The Sovereign Tech Agency’s survey of over 500 OSS maintainers showed that a third of them are not paid at all for their maintenance work, but would like to be. Another third earns some income from OSS maintenance, but is not able to make a living off this work. Perhaps even more alarmingly, a third of respondents are solo maintainers, and almost three quarters of surveyed projects are maintained by three people or fewer. As prominent security incidents such as the xz backdoor or the Log4Shell vulnerability have shown in recent years, it can mean serious risks for the OSS community’s health and the security of our global software ecosystem if too much is put on the shoulders of small, overworked, and underappreciated teams. At GitHub, we are helping address this open source sustainability challenge through GitHub Sponsors, the GitHub Secure Open Source Fund, free security tooling for maintainers, and other initiatives. Yet we recognize that there is a significant gap between the immense public value of open source software and the funding that is available to maintain it, a gap that this research is seeking to address. Designing an impactful fund Building on the success story of the German Sovereign Tech Agency, which has invested over €23 million in 60 OSS projects in its first two years of operation (2022-2024), the EU-STF should have five main areas of activity: Identifying the EU’s most critical open source dependencies, Investments in maintenance, Investments in security, Investments in improvement, Strengthening the open source ecosystem. The study proposes two alternative institutional setups for the EU-STF: either the creation of a centralized EU institution (the moonshot model), or a consortium of EU member states that provide the initial funding and apply for additional resources from the EU budget (the pragmatic model). In both cases, to make the fund a success, the minimum contribution from the upcoming EU multiannual budget should be no less than €350 million. This would not be enough to meet the open source maintenance need, but it could form the basis for leveraging industry and national government co-financing that would make a lasting impact. Equipped with the learnings from the German Sovereign Tech Agency and other government open source programs, such as the US Open Technology Fund or the EU’s Next Generation Internet initiative, the study identified seven design criteria that the EU-STF must meet: Pooled financing. To address the maintenance funding gap, industry, national governments and the EU should all be able to put money into the same pot. It is not in the interest of overworked open source maintainers to have to research and apply to dozens of separate funds, all with slightly different funding criteria. That’s why GitHub’s Secure Open Source Fund pools funding from many industry partners into one coherent program. The EU-STF should follow the same logic and be capable of collecting contributions from industry, national governments and the EU budget alike. Low bureaucracy. If you’re one of those aforementioned unpaid solo maintainers, the last thing you need is to sink several days of work into a complicated application process with an uncertain outcome that many EU funding programs are unfortunately known for. The EU-STF should combine a lightweight application process along with its own research to identify and proactively contact critical OSS infrastructure projects. Funding recipients should have limited reporting requirements to make sure that they can spend their time on improving the health of their OSS projects, not jumping through administrative hoops. Political independence. Public funding programs often follow technological trends, such as blockchain, quantum computing or AI. Open source maintenance often gets overlooked, because it is neither a new development nor limited to a particular economic sector: it is foundational to all of them. An EU-STF has to be politically independent enough to shield it from frequent pivots to new, politically salient topics, and instead keep it focused on the mission of securing and maintaining our public software infrastructure. Flexible funding. There is no one-size-fits-all model for open source maintenance. Many maintainers are hired by companies to work on OSS as part of their day jobs. Others maintain projects in their free time. Some critical OSS projects are governed by a foundation or other nonprofit, yet others are made up of a loose collective of individuals scattered across the globe.

If you’ve ever dusted off an old project and thought, “How did I leave things in such a mess?”, you’re in good company. On my latest Rubber Duck Thursdays stream, I dove back into my OctoArcade Next.js app, only to rediscover a host of UI gremlins. So, we experimented with something that felt like magic: letting GitHub Copilot agent mode, paired with Playwright MCP server, identify and fix UI bugs. Along the way, I learned (again) how crucial it is to provide AI tools like Copilot with clear, detailed requirements.  Let’s walk through how I used these agentic tools to debug, test, and (mostly) solve some tricky layout issues, while covering practical tips for anyone looking to leverage Copilot’s agent workflows in real-world projects. 💡 Useful Links Use agent mode in VS Code Use MCP servers in VS Code Playwright MCP The setup: Revisiting OctoArcade (and its bugs) I started by firing up OctoArcade, my collection of GitHub-themed mini-games built with Next.js and TypeScript. Within minutes, I realized I had been introducing a new game to the app, but hadn’t quite gotten around to fixing some bugs. Here’s what we accomplished in one stream session: Problem: Navigation header overlapping game content across all games Solution: Copilot agent mode and Playwright MCP server identified the issue through visual inspection, and implemented a global header fix Bonus: Fixed some additional UI issues (unintended gaps between the game canvas and footer) discovered during testing Result: Hands-off debugging that solved problems I’d stepped away from, and had previously spent some cycles on fixing Let me walk you through how this worked and what you can learn for your own debugging workflows. Making sure Copilot custom instructions are set up With my environment set up in VS Code Insiders, I checked that my Copilot custom instruction files (.github/copilot-instructions.md, *.instructions.md files) were up to date. This is usually my first step before using any agentic features, as these instructions provide important context on my expectations, coding styles, and working practices — influencing how Copilot responds and interacts with my codebase. In my last blog post, we spent time exploring recommended practices when setting up Copilot custom instructions. We also covered how the copilot-setup-steps.yml sets up a developer environment when using Copilot coding agent. Take a look at that blog post on using GitHub Copilot coding agents to refactor and automate developer workflows to learn more. 💡 Did you know? Learn more about instruction files: Adding repository custom instructions for GitHub Copilot (with instructions for different editors) Adding custom instructions to your repository is my go-to reference, as I personally find the structure of the file very helpful github/awesome-copilot has a collection of community contributed instructions, reusable prompts, chat modes and more Always keep your Copilot custom instructions current (including descriptions of your repository structure, common steps like building and testing, and any expectations before making commits). Copilot agents depend on this context to deliver relevant changes. When I think my instructions file is out of date, I typically prompt Copilot in agent mode with a prompt along the lines of: Based on the #codebase, please can you update the custom instructions file for accuracy? Please make sure to keep the structure (i.e. headings etc.) as-is. Thanks! In some of my instruction files, I’ve even instructed Copilot to keep key documentation (README, .github/copilot-instructions.md, etc.) up to date when it makes significant changes (like refactoring files or adding new features). Agentic debugging: UI troubleshooting with Playwright MCP Playwright MCP server is a powerful tool for end-to-end testing and UI automation. Since it’s an MCP server, you can access it through your favorite AI tools that support the Model Context Protocol, like Copilot agent mode and Copilot coding agent! In agent mode, Copilot can use Playwright’s structured tools to: Load web pages Simulate user actions (clicks, navigation) Inspect rendered layouts without needing vision models This means you can ask Copilot to “see” what a human would, spot layout issues, and even propose CSS or component fixes. To get started with Playwright, it’s as easy as adding the below to your MCP configuration: {   “mcpServers”: {     “playwright”: {       “command”: “npx”,       “args”: [“@playwright/mcp@latest”]     }   } } Once you have started the MCP server, you should see that Copilot now has access to a suite of new tools for browser interaction like: browser_snapshot – Capture accessibility snapshots of pages browser_navigate – Navigate to URLs browser_click, browser_type, browser_hover – Interact with elements browser_resize – Test different viewport sizes browser_take_screenshot – Visual documentation And many more: You can find the full list in the tools section of Playwright MCP server’s README With access to a new set of tools to solve the UI challenges, it was time to point Copilot at the problem. Meaning, I now had the task of clearly defining the requirements in my initial prompt…easier said than done. The debugging journey: Real-time fixes and lessons learned 1. Describe the problem and let agent mode work I noticed that, in several pages, the main content was tucked behind the navigation bar. This was particularly noticeable on any pages that rendered games. On some pages (like OctoPong), I saw inconsistent spacing between game elements and the footer. To get Copilot agent mode started, I aimed to be as explicit as possible in my prompts: I have spotted that there is a bit of a UI error. It seems like the main content of any page “starts” behind the navigation bar. This is more evident on the games like octosnap, octopong and octobrickbreaker. Can you take a look at the site using Playwright (you’ll need to spin up an instance of the server), take a look at the pages, and then investigate? Thanks! It loaded up the pages to configure each game, but didn’t try loading the games themselves (so missed some context). I followed up in a separate prompt: Sorry, I wanted you to take a look when a game is actually loaded too. Can you play the game Octopong and Octosnap –

AI features can make an open source project shine. At least, until setup asks for a paid inference API key.  Requiring contributors or even casual users to bring their own large language model (LLM) key stops adoption in its tracks: $ my-cool-ai-tool Error: OPENAI_API_KEY not found Developers may not want to buy a paid plan just to try out your tool, and self hosting a model can be too heavy for laptops or GitHub Actions runners.  GitHub Models solves that friction with a free, OpenAI-compatible inference API that every GitHub account can use with no new keys, consoles, or SDKs required. In this article, we’ll show you how to drop it into your project, run it in CI/CD, and scale when your community takes off. Let’s jump in. The hidden cost of “just add AI” AI features feel ubiquitous today, but getting them running locally is still a challenge for a few reasons: Paid APIs: The simplest path is to ask users for an OpenAI or Anthropic key. That’s a non-starter for many hobbyists and students because paid APIs are too expensive. Local models: Running a 2 B-parameter LLM can work for lightweight tasks, but anything that requires more intelligence will quickly blow past typical laptop memory — let alone the 14 GB container that backs a GitHub Actions runner. Docker images and weights: You can bundle a model with your app, but distributing multi-gigabyte weights balloons install size and slows CI. Every additional requirement filters out potential users and contributors. What you need is an inference endpoint that’s: Free for public projects Compatible with existing OpenAI SDKs Available wherever your code runs, like your laptop, server, or Actions runner That’s what GitHub Models provides. GitHub Models in a nutshell What it is: A REST endpoint that speaks the chat/completions spec you already know. What you get: A curated set of models (GPT-4o, DeepSeek-R1, Llama 3, and more) hosted by GitHub. Who can call it: Anyone with a GitHub Personal Access Token (PAT), or a repository’s built-in GITHUB_TOKEN when you opt-in via permissions. How much it costs: Free tier for all personal accounts and OSS orgs; metered paid tier unlocks higher throughput and larger context windows. Because the API mirrors OpenAI’s, any client that accepts a baseURL will work without code changes. This includes OpenAI-JS, OpenAI Python, LangChain, llamacpp, or your own curl script. How to get started with GitHub Models Since GitHub Models is compatible with the OpenAI chat/completions API, almost every inference SDK can use it. To get started, you can use the OpenAI SDK: import OpenAI from “openai”; const openai = new OpenAI({ baseURL: “https://models.github.ai/inference/chat/completions”, apiKey: process.env.GITHUB_TOKEN // or any PAT with models:read }); const res = await openai.chat.completions.create({ model: “openai/gpt-4o”, messages: [{ role: “user”, content: “Hi!” }] }); console.log(res.choices[0].message.content); If you write your AI open source software with GitHub Models as an inference provider, all GitHub users will be able to get up and running with it just by supplying a GitHub Personal Access Token (PAT). And if your software runs in GitHub Actions, your users won’t even need to supply a PAT. By requesting the models: read permission in your workflow file, the built-in GitHub token will have permissions to make inference requests to GitHub Models. This means you can build a whole array of AI-powered Actions that can be shared and installed with a single click. For instance: Code review or PR triage bots Smart issue tagging workflows Weekly repository activity report generators And anything else that a GitHub Action can do Plus, using GitHub Models makes it easy for your users to set up AI inference. And that has another positive effect: it’s easier for your contributors to set up AI inference as well. When anyone with a GitHub account can run your code end to end, you’ll be able to get contributions from the whole range of GitHub users, not just the ones with an OpenAI key. Zero-configuration CI with GitHub Actions Publishing an Action that relies on AI used to require users to add their inference API key as a GitHub Actions secret. Now you can ship a one-click install: yaml # .github/workflows/triage.yml permissions: contents: read issues: write models: read # 👈 unlocks GitHub Models for the GITHUB_TOKEN jobs: triage: runs-on: ubuntu-latest steps: – uses: actions/checkout@v4 – name: Smart issue triage run: node scripts/triage.js The runner’s GITHUB_TOKEN carries the models:read scope, so your Action can call any model without extra setup. This makes it well suited for: Automated pull request summaries Issue deduplication and tagging Weekly repository digests Anything else you can script in an Action Scaling when your project takes off The GitHub Models inference API is free for everyone. But if you or your users want to do more inference than the free rate limits allow, you can turn on paid inference in your settings for significantly larger context windows and higher requests-per-minute.  When your community grows, so will traffic. So it’s important to consider the following:  Requests per minute (RPM): While the free tier offers default limits, the paid tier offers multiples higher. Context window: Free tier tops out at standard model limits; paid enables 128k tokens on supported models. Latency: The paid tier runs in its own separate deployment, so you’re not in the same queue as free tier users. To get started, you can enable paid usage in Settings > Models for your org or enterprise. Your existing clients and tokens will keep working (but they’ll be faster and support bigger contexts). Take this with you LLMs are transforming how developers build and ship software, but requiring users to supply their own paid API key can be a barrier to entry. The magic only happens when the first npm install, cargo run, or go test just works. If you maintain an AI-powered open source codebase, you should consider adding GitHub Models as a default inference provider. Your users already have free AI inference via GitHub, so there’s little downside to letting them use it with

Model Context Protocol (MCP) enables AI agents to connect to external tools and data sources without having to implement API-specific connectors. Whether you’re extracting key data from invoices, summarizing support tickets, or searching for code snippets across a large codebase, MCP provides a standardized way to connect LLMs with the context they need.  Below we’ll dig into why security is such a crucial component to MCP usage, especially with a recent specification release, as well as how developers of both MCP clients and MCP servers can build secure integrations from the get-go. Why security matters for MCP Unlike traditional APIs that serve known clients in somewhat controlled environments, MCP servers act as bridges between AI agents and an unlimited number of data sources that can include sensitive enterprise resources. So, a security breach won’t just compromise data — it can give malicious actors the ability to manipulate AI behavior and access connected systems. To help prevent common pitfalls, the MCP specification now includes security guidelines and best practices that address common attack vectors, like confused deputy problems, token passthrough vulnerabilities, and session hijacking. Following these patterns from the start can help you build systems that can handle sensitive tools and data. Understanding the MCP authorization The MCP specification uses OAuth 2.1 for secure authorization. This allows MCP, at the protocol level, to take advantage of many modern security capabilities, including: Authorization server discovery: MCP servers implement OAuth 2.0 Protected Resource Metadata (PRM) (RFC 9728) to advertise the authorization servers that they support. When a client attempts to access a protected MCP server, the server will respond with a HTTP 401 Unauthorized and include a WWW-Authenticate header pointing to the metadata endpoint. Dynamic client registration: This is automatic client registration using OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591). This removes the need for manual client setup when AI agents connect to MCP servers dynamically. Resource indicators: The specification also mandates RFC 8707 Resource Indicators, ensuring that tokens are bound to specific MCP servers. This prevents token reuse attacks and helps maintain clear security boundaries. Even with the latest changes to authorization specs, like the clean split between the responsibilities of the authorization server and the resource server, developers don’t need to worry about implementing security infrastructure from scratch. (Because the requirement to follow the OAuth2.1 conventions didn’t change.) So developers can just use off-the-shelf authorization servers and identity providers.  Because MCP requires implementers to snap to OAuth 2.1 as the default approach to authorization, this also means that developers can use existing OAuth libraries to build the authorization capabilities into their MCP servers without anything super-custom. This is a massive time and effort saver. The complete authorization flow When it comes to connecting to protected MCP servers, a MCP client will need to somehow find out what credentials the server needs. Luckily, because of the aforementioned discovery mechanism, this is a relatively straightforward flow: Discovery phase. MCP client attempts to access MCP server without credentials (that is a token). Server response. MCP server returns a HTTP 401 Unauthorized response with a metadata URL in the WWW-Authenticate header. Metadata retrieval. MCP client fetches Protected Resource Metadata, parses it, and then gets the authorization server endpoints. Client registration. MCP client automatically registers with authorization server (if supported). Some clients may be pre-registered. Authorization request. MCP client initiates OAuth flow with Proof Key for Code Exchange (PKCE) and the resource parameter. User consent. The user authorizes access through the authorization server. Token exchange. MCP client exchanges authorization code for access token. Authenticated requests. All subsequent requests from MCP client to MCP server include Bearer token. Nothing in the flow here is MCP-specific, and that’s the beauty of MCP snapping to a common industry standard. There’s no need to reinvent the wheel because a robust solution already exists. Implementing authorization in MCP Most OAuth providers work well for MCP server authorization without any additional configuration, though one of the more challenging gaps today is the availability of Dynamic Client Registration. However, support for that feature is slowly rolling out across the identity ecosystem, and we expect it to be more common as MCP gains traction. Aside from the authorization server, when implementing authorization for your MCP server, you will need to consider several key components and behaviors: PRM endpoint. The MCP server must implement the /.well-known/oauth-protected-resource endpoint to advertise supported authorization server scopes. The MCP TypeScript SDK already integrates this capability natively, with other MCP SDK support coming very soon. Token validation middleware. You need to make sure that your MCP server is only accepting tokens meant for it. Many open source solutions, like PyJWT, can help you here by: Extracting Bearer tokens from Authorization headers Validating token signatures using your OAuth provider’s JSON Web Key Sets (JWKS) endpoint Checking token expiration and audience claims Ensuring tokens were issued specifically for your MCP server (this part is critical for the security of your infrastructure) Error handling. Your MCP server will need to return proper HTTP status codes (HTTP 401 Unauthorized for missing/invalid tokens, HTTP 403 Forbidden for insufficient permissions) with appropriate WWW-Authenticate headers. Anthropic, together with the broader MCP community, is working on integrating a lot of these capabilities directly into the MCP SDKs, removing the need to implement many of the requirements from scratch. For MCP server developers, this will be the recommended path when it comes to building implementations that conform to the MCP specification and will be able to work with any MCP client out there. Handling multi-user scenarios Multi-tenancy in MCP servers introduces unique security challenges that go beyond simple authorization and token validation. When your MCP server handles requests from multiple users — each with their own identities, permissions, and data — you must enforce strict boundaries to prevent unauthorized access and data leakage. This is a classic “confused deputy” problem, where a legitimate user could inadvertently trick the MCP server into accessing resources they shouldn’t. OAuth tokens are the foundation for securely identifying users. They often contain

What started in 2006 with just 40 farm families in western Kenya has grown into a powerful movement. Today, One Acre Fund serves 5 million farm families across ten countries in eastern and southern Africa. Their ambitious goal? By 2030, they aim to support 10 million farm families annually. How? By using open source technology and AI, aiming to generate an astounding $1 billion in new revenue for these communities. Cultivating impact with technology For smallholder farmers — those typically working with an acre or less of land — intensifying agriculture is crucial for their prosperity. This process of producing more food with the same amount of land, not only brings higher crop yields, but stimulates the economy, strengthens community, and enables farmers to scale. One Acre Fund’s core mission is to empower these farmers, providing a direct pathway out of poverty. But unlike traditional microfinance, they don’t just loan cash. Instead, they provide vital farm resources like fertilizer and seed, plus training and services, directly equipping farmers with the tools they need to succeed. They also help the farmers they serve to improve their soil health and plant trees to not only increase yields but also help farmers be more resilient to weather changes due to climate change. In the past, farmers used to fear using technology. But, as we provide training to them, they’re now eager to use it. Blaise Murame, Regional Lead, One Acre Fund Technology is at the heart of One Acre Fund’s rapid growth. They’ve transitioned from an entirely analog approach — meeting farmers in the field with paper records — to a highly digitized system. This transformation has revolutionized their operations, making everything from logistics and delivery to farmer registration and the development of training materials more efficient. Farmers, initially hesitant, are now eager to embrace this tech, after receiving resources and tools on time and achieving their goals faster than ever before. Growing products to empower farmers A significant part of One Acre Fund’s tech leap comes from their adoption of GitHub Copilot.  Since the coming of GitHub Copilot, the time it used to take us three weeks, that development work can be finished within a week. That’s affecting our goals – we’re able to set more goals than last year. Yididiya Gebredingel, Developer, One Acre Fund By introducing GitHub Copilot, One Acre Fund has been able to move much faster on their development, and they can focus on the pieces that are actually creating impact in the field. This acceleration has enabled them to set and achieve more goals, with developers completing projects three times faster and over 30% of their work being assisted by AI. As a nonprofit, working with some of the world’s poorest populations means operating on razor-thin margins.This makes the cost-effectiveness of their solutions paramount. Open source technology provides the ideal balance, offering both “solution maturity and solution flexibility” without the burden of exponentially growing license fees as they scale. Embracing the open source community is a strategic move for One Acre Fund, as they’ve migrated most of their core operational systems to open source to leverage collaborative development and community support. As a nonprofit, we can’t tolerate license fees that will grow exponentially as we scale. Open source gives us the right balance between solution maturity and solution flexibility. Sarah Hylden, Global Director of Operations, One Acre Fund Ultimately, One Acre Fund believes that if you have an intervention that works to create a sustainable pathway out of poverty for farmers, and you know it works, then you have a moral obligation to scale it. And with the help of GitHub Copilot, they are doing just that — moving faster and making a greater impact in the lives of millions of farm families. Explore a better way of working by trying GitHub Copilot for free today, or if you’re a nonprofit organization, check out GitHub for Nonprofits for exclusive discounts. The post Scaling for impact: How GitHub Copilot supercharges smallholder farmers appeared first on The GitHub Blog. ​ Open Source, Social impact, GitHub Copilot The GitHub Blog

Running the Model Context Protocol (MCP) server locally works, but managing Docker, rotating access tokens, and pulling updates is a hassle. GitHub’s managed MCP endpoint eliminates these infrastructure headaches, letting you focus on what you love — shipping code. In this 201-level tutorial, we’ll walk through upgrading from the local MCP setup to GitHub’s managed endpoint. You’ll get OAuth authentication, automatic updates, and access to toolsets that open the door to richer AI workflows you simply can’t pull off with a bare‑bones local runtime. You’ll also learn how to customize tool access with read-only modes, streamline your AI workflows with dynamic toolsets, and get ready for agent-to-agent collaboration using GitHub Copilot. The GitHub remote  MCP server is GitHub’s fully hosted, always‑up‑to‑date implementation of MCP Instead of wrestling with Docker and personal access tokens on your machine, you point your IDE or agent host to https://api.githubcopilot.com/mcp/ and authenticate once with OAuth. GitHub handles the rest. With our server, we enable the following toolsets by default, but you can disable anything you don’t need with a simple flag when you start the server:  Repository intelligence: Search code, stream files, and open pull requests without a local clone. Issue and pull request automation: File, triage, label, review, and even merge from a single agent prompt. CI/CD visibility: Inspect workflow runs, fetch logs, and re‑run failed jobs right inside chat. Security insights: Surface code scanning and Dependabot alerts so fixes land before exploits do. Fine‑grained controls: Toggle specific toolsets or flip the server to read‑only for extra safety. Get started > But first, why switch to our hosted server?  Running the open source MCP server locally works, but it carries hidden costs. Here’s what changes when you go remote: Local Docker server Hosted MCP endpoint Maintain a Docker image, upgrade manually GitHub patches and upgrades automatically Manage personal‑access tokens (PATs) Sign in once with OAuth; scopes handled for you Expose the server on localhost only Reachable from any IDE or remote‑dev box Full write access unless you customise the binary Built-in read‑only switch and per‑toolset flags If you need an air‑gapped environment, stick with local. For most teams, the hosted server eliminates infrastructure work and lets you focus on automation. With that, let’s dive in. A few things you need before you get started: GitHub Copilot or Copilot Enterprise seat VS Code 1.92+ (or another MCP‑capable client) Network access to https://api.githubcopilot.com A test repository to experiment with Step 1: Install the remote MCP server Setting up GitHub’s remote MCP server server is a breeze compared to local Docker-based installations. Hosted by GitHub, it eliminates the need for managing Docker containers or manually handling updates, offering a streamlined, cloud-native experience. How to install the remote server on VS Code or VS Code Insiders: Open the command palette and run:> GitHub MCP: Install Remote Server Complete the OAuth flow to connect your GitHub account. Restart the server to finish setup. For any other client Set the server URL to: https://api.githubcopilot.com/mcp/ Then authenticate when prompted. Validate your connection with a quick check curl -I https://api.githubcopilot.com/mcp/healthz # HTTP/1.1 200 OK If you see 200 OK, you’re good to go. Once installed, the remote server replaces the local one, and you’re ready to roll. That means no more Docker or tokens, just a simple integration. Step 2: Configure access controls Use read-only mode for safe exploration. Working in a sensitive environment? Testing in production? Demoing to stakeholders? Flip the server to read-only mode: { “servers”: { “github”: { “type”: “http”, “url”: “https://api.githubcopilot.com/mcp/”, “mode”: “read-only” } } } The agent can read issues, pull requests, and code but can’t push changes. Perfect for code reviews where you want context without risk. Use case: Pull request viewer Need to review pull requests without modifying anything? This setup gives you safe, read-only access — perfect for browsing changes, leaving comments, or gathering context without risk of altering code. Go to the GitHub MCP server repo. Navigate to the “Remote Server” section. Choose the pull request read-only variant. Click Install Read Only. You’ll now see tools like listPullRequests, getPullRequest, and searchPullRequests, but no write access. And since these tools don’t make changes, VS Code skips the permission prompts for a seamless experience. Limit scope with selective toolsets Keep both developers and agents focused by exposing only the tools you need with the following command: “toolsets”: [“context”, “issues”, “pull_requests”] Add this array next to the mode field to hide everything else. Step 3: Try it out with these three hands-on examples Want to see how Copilot agent mode works in practice? These real-world examples show how the agent can handle everyday developer tasks — like managing pull requests, debugging workflows, and triaging security alerts — without needing local setup or manual digging. Just prompt and go. Example 1: Add a CODEOWNERS file and open a pull request Open your repo ➜ Ask Copilot Agent. Prompt your agent: “Add a CODEOWNERS file for /api/** assigning @backend-team, then open a draft pull request.” The agent will: Use repos.create_file to add the CODEOWNERS file. Call pull_requests.open to create the pull request. Execute pull_requests.request_reviewers to assign reviewers. No local cloning, no manual file creation. Just prompt and ship. Example 2: Debug a failed workflow Prompt: “Why did the release.yml job fail last night?” The agent pulls logs with actions.get_workflow_run_logs, analyzes the stack trace, and suggests fixes. It’s like having a senior engineer review your CI/CD failures. Example 3: Triage security alerts Prompt: “List critical Dependabot alerts across all my repos and create issues for each.”  The server returns alerts via dependabot.list_dependabot_alerts, then the agent creates focused issues only where needed. Step 4: Troubleshooting tips with the GitHub remote MCP server  Symptom Likely cause Fix 401 Unauthorized on install Left‑over GITHUB_TOKEN env var Unset the var and rerun OAuth flow Tools don’t appear Corporate proxy blocks api.githubcopilot.com Add proxy settings or allowlist the domain Model times out Large toolset enabled Restrict to needed toolsets only Step 5: Streamline your workflow with dynamic toolsets The full MCP server includes over 70 tools, and, while

What makes open source work, and why do so many of us keep showing up to build together? On the GitHub Podcast, we dive into the stories behind the code: the projects, the people, and the ideas shaping the open source ecosystem. At GitHub, we know open source has always been the launchpad for what’s next. But 2025 feels different. Everything new in software from AI agents to edge runtimes to climate-tech dashboards starts life in a public repository where anyone can fork, remix, and improve it overnight. When you invest in that commons, you’re not just sponsoring code; you’re underwriting the world’s R&D engine.  And that’s what we want to explore in our latest podcast with an eye towards everything that makes open source what it is today.  (And yes, we also answer essential questions like: how exactly do you do a hackathon on a plane?) Meet the core contributors I’m joined by an amazing crew of rotating hosts including Cassidy Williams, Kedasha Kerr, Andrea Griffiths, and me, Abby Cabunoc Mayes — all of us long-time contributors to different parts of the open source world. Together, we’ll explore what’s exciting, challenging, and evolving in open source today. Whether it’s community building, open science, developer education, or building in public, we each bring a unique perspective to the conversation. In today’s episode, we introduce ourselves, share how we got involved in open source, and reflect on what keeps us going. We talk about the importance of creating beginner content in a world seemingly saturated with beginner developer content with Kedasha, and Cassidy talks about how overhearing a conversation as a teenager sparked her love of code.  Plus, we spotlight some of our favorite open source projects that have caught our eyes this week. Here’s a sneak peek: Anime.JS, a visually stunning JavaScript animation library that sparks creativity. Docs, a collaborative open source document editor developed by the French and German governments. CSS Zero, a no-build frontend starter kit that simplifies web development. What’s in the build? Every two weeks we’ll share a new episode with stories from maintainers, contributors, and builders across the open source ecosystem. We’ll talk about tools, standards, and the side projects that spark joy (and sometimes chaos). You’ll also hear from special guests like Jason Lengstorf, who makes TV for developers, and Keeley Hammond, a core maintainer of Electron, who’ll share their own journeys and insights. Whether you’re just getting started, or you’ve been maintaining projects for years, there’s something here for you. Coming up next: we dive into the Model Context Protocol (MCP), what it is, why it matters, and how it’s helping make AI tools more transparent and interoperable. We’ll explore how MCP builds on the long history of open standards, and what it unlocks for developers today. Don’t want to miss out? Subscribe now to stay up to date on our latest episodes. The post From first commits to big ships: Tune into our new open source podcast appeared first on The GitHub Blog. ​ Maintainers, Open Source, GitHub Podcast, open source, open source community The GitHub Blog

We often describe GitHub Copilot as an AI peer programmer, or an AI member of the team. With agentic features like coding agent, you can assign issues to Copilot, and it will diligently get to work behind the scenes, creating a proposed solution to the problem, all without even asking for a cup of coffee. Much of the initial setup for Copilot coding agent is similar to onboarding a new developer – like providing good documentation and streamlining the setup process. But since it’s AI, there are a few things that make Copilot unique as a team member (aside from it not needing caffeine). So let’s explore how this is done. We’ll start by examining the flow Copilot coding agent follows, and key strategies to ensure Copilot has the resources it needs to generate the best possible pull request. Agentic workflows in GitHub Copilot: coding agent vs. agent mode GitHub Copilot comes with two key agentic capabilities: coding agent and agent mode. Think of coding agent as an autonomous tool: you give Copilot an issue, it spins up an Actions container, iterates in the background, and comes back with a pull request (PR). Agent mode is “stay in the loop:” an interactive sidekick in the editor or on github.com that executes smaller, multi-step tasks with you in real time. Same brain, different engagement model where one’s async and pull request–oriented, while the other’s conversational and immediate. Learn more >  Inside Copilot coding agent’s workflow: From issue to ready‑to‑review pull request When you assign an issue to Copilot, it follows a set pattern: Creates a branch for the code it will create. Creates a pull request to track its work and communicate with the team. Creates a contained environment for its work (running inside GitHub Actions). Reads the issue or prompt to understand the requested task. Explores the project to determine the best approach to tackle the problem. Works iteratively toward a solution. Finalizes its work, updates the pull request, and notifies the team the pull request is ready to be reviewed. By understanding this flow, we can work to ensure Copilot is set up for success. The first two steps — creating the pull request and branch — are self-contained, and there’s no additional work for us to do to help Copilot.  So, let’s skip right to the third step — the environment — where we can configure everything Copilot might need in the environment where it’ll write the code and run tasks as it generates the pull request. Configure Copilot’s environment with GitHub Actions In keeping with the analogy of onboarding a new developer, let’s consider the environment in which GitHub Copilot — or really any developer — does its work. Before you’re able to be productive, you need specific services, libraries, and frameworks installed. Copilot is the exact same. In order for Copilot to add a new feature and run the necessary tests to ensure everything works, it needs access to all the tooling the rest of your team has. We’ll do this with a custom workflow file. Coding agent uses a container running inside GitHub Actions. If you’re not already familiar with Actions, it’s our automation platform, and is configured using YAML files, which describe the necessary tasks that need to be completed.  Actions is often used for CI/CD, so tasks like testing, deployment, etc. In this case, Actions hosts the container coding agent will use for its work. And we can take advantage of the ability to script tasks in YAML to ensure said container is set up correctly! 💡Pro tip: There’s a good chance you already have a workflow for creating an environment, which could be used for development — say like the one used when running various tests or validation scripts. You can absolutely reuse those workflows for Copilot coding agent’s environment! Example Copilot setup workflow file To do this, create a new workflow file located at .github/workflows/copilot-setup-steps.yml with a job titled copilot-setup-steps. Inside the job, you’ll list all of the steps to install the necessary requirements for the environment. Let’s say, for example, we’re building a Python app that uses SQLite. We could have a workflow file like the following, which will be run to set up the environment for Copilot: name: “Copilot Setup Steps” # Automatically run the setup steps when they are changed # Allows for streamlined validation, # and allow manual testing through the repository’s “Actions” tab on: workflow_dispatch: push: paths: – .github/workflows/copilot-setup-steps.yml pull_request: paths: – .github/workflows/copilot-setup-steps.yml jobs: # The job MUST be called `copilot-setup-steps` # otherwise it will not be picked up by Copilot. copilot-setup-steps: runs-on: ubuntu-latest # Permissions set just for the setup steps # Copilot has permissions to its branch permissions: # To allow us to clone the repo for setup contents: read # The setup steps – install Python and our dependencies steps: – name: Checkout code uses: actions/checkout@v4 – name: Set up Python uses: actions/setup-python@v4 with: python-version: “3.13” cache: “pip” – name: Install Python dependencies run: pip install -r requirements.txt – name: Install SQLite run: sudo apt update && sudo apt install sqlite3 Whenever an issue is assigned to Copilot, it will run this workflow to configure its environment so it’ll have everything it needs! 💡 Pro tip: If you know something should be done a particular way, tell Copilot! In our above example, Copilot could install the requisite services on its own. However, doing so may lead to unexpected versions or other mistakes. As I always like to joke, don’t be passive aggressive with Copilot. 😀 Set Copilot up for success with well-written issues and prompts Speaking of not being passive aggressive, now’s the perfect time to focus on the next step Copilot follows: reading the issue. This will be Copilot’s entry point into creating the pull request you’ll later review. Remember that the more clearly defined the issue, the better quality the pull request.  The best approach is to think about how you’d like to see the first issue you’re assigned on